> Er, by "permission" I meant it doesn't make the _implementation_
> non-compliant.
No, it doesn-t make cthe compiler non-complaint, but it makes your
code non complaint.
> And implementation-defined is not the same as undefined.
I perfectly know it, but in this case it is not exactly said
if
On 20 November 2014 15:19, Maxime Coste wrote:
> On Thu, Nov 20, 2014 at 07:56:29AM +0100, ans...@garbe.us wrote:
>> > But regarding the typedefs for structs: C has only a few namespace
>> > features, so lets not dismantle the probably most used one, alright?
>> > "struct stat" can be something di
On Thu, Nov 20, 2014 at 07:56:29AM +0100, ans...@garbe.us wrote:
> > But regarding the typedefs for structs: C has only a few namespace
> > features, so lets not dismantle the probably most used one, alright?
> > "struct stat" can be something different from "stat()"! I like that
> > namespace thin
On Wed, Nov 19, 2014, at 16:44, k...@shike2.com wrote:
> > C90, or any version of standard C, does not have a concept of "system
> > headers", other than giving implementations permission to place their
> > own implementation-defined files in places searched by #include
> > .
>
> At this point I
k...@shike2.com wrote:
> For long time I followed the rule of kernel style of not using typedef
> ever, but I changed it to the rule of using typedef only with structs
> and capital letter, and I can say that this last is far better; You
> get more readable function definitions:
Not typedefing rea
On 20 November 2014 06:31, Markus Wichmann wrote:
> On Wed, Nov 19, 2014 at 07:58:28PM +0100, k...@shike2.com wrote:
>> For long time I followed the rule of kernel style of not using typedef
>> ever, but I changed it to the rule of using typedef only with structs
>> and capital letter, and I can s
On 19 November 2014 22:51, Evan Gates wrote:
> On Wed, Nov 19, 2014 at 6:23 AM, Anselm R Garbe wrote:
>> I suggest http://suckless.org/style[.md], to be the central place for this.
>>
>> @Evan, feel free to proceed ;)
>
> I just submitted a first draft doing my best to include everything
> that w
On Wed, Nov 19, 2014 at 07:58:28PM +0100, k...@shike2.com wrote:
> For long time I followed the rule of kernel style of not using typedef
> ever, but I changed it to the rule of using typedef only with structs
> and capital letter, and I can say that this last is far better; You
> get more readable
On Wed, Nov 19, 2014 at 6:23 AM, Anselm R Garbe wrote:
> I suggest http://suckless.org/style[.md], to be the central place for this.
>
> @Evan, feel free to proceed ;)
I just submitted a first draft doing my best to include everything
that was mentioned here. As always it is most definitely a wor
> C90, or any version of standard C, does not have a concept of "system
> headers", other than giving implementations permission to place their
> own implementation-defined files in places searched by #include
> .
At this point I was talking about POSIX of course. C90 doesn't give
implementations
On Wed, Nov 19, 2014, at 13:51, k...@shike2.com wrote:
>
> > system headers should come first, then a newline, then libc headers
> > then a newline then local headers.
>
>
> I usually do just the inverse, first libc headers and later system
> headers.
>
> > the libc headers are guaranteed to wo
>>> types
>>> =
>>> user defined types start with a capital letter
>>> when possible typedef struct {} Name;
>>
>> Debatable. I'd like to hear more opinions on this.
>
> In most suckless code types always start with capital letters (pretty
> much acme/p9 influenced), as opposed to lower cas
> On Tue, Nov 18, 2014 at 09:53:33AM -0500, Greg Reagle wrote:
>> Another way to provide style guidance is to refer to a particular source
>> file or project as an epitome or paragon, if such a paragon exists That
>> takes much less time than explicitly developing a style guide.
>
> Yes my initia
On Wed, Nov 19, 2014 at 07:51:48PM +0100, k...@shike2.com wrote:
> Are you sure about that?. I know that C90 guarantees that any
> standard header will not include any other standard header (althought
> it is sad that a lot of compilers ignore this rule), but I have never
> read anything about dep
>> types
>> =
>> user defined types start with a capital letter
>> when possible typedef struct {} Name;
>
> Debatable. I'd like to hear more opinions on this.
For long time I followed the rule of kernel style of not using typedef
ever, but I changed it to the rule of using typedef only w
> system headers should come first, then a newline, then libc headers
> then a newline then local headers.
I usually do just the inverse, first libc headers and later system
headers.
> the libc headers are guaranteed to work regardless of the order of
> inclusion but need to come after the syst
>> > By default I read if (!functioncall()) as 'if the function call
>> > failed'. I like the (strcmp(p, q) == 0) idiom because I don't fall
>> > into the trap of reading the statement as 'if the string comparison
>> > failed'. It is the one case I can think of where I prefer an explicit
>> > co
>
>> variables
>> =
>> declaration of pointer, * is adjacent to variable not type (as it's
>> part of the variable not the type, avoids int* i, j; etc.)
>
> This is a very smart point. I see this very often, even though not
> in sbase. a grouped declaration "int* a, b, c;" could falsl
On 19 November 2014 15:46, Dimitris Papastamos wrote:
> On Wed, Nov 19, 2014 at 03:43:03PM +0100, Markus Teich wrote:
>> for structs I hate to use a typedef since it hides the fact that it is a
>> struct
>> beeing handled. If you propose that the only names starting with an uppercase
>> letter ar
On Wed, Nov 19, 2014 at 03:43:03PM +0100, Markus Teich wrote:
> for structs I hate to use a typedef since it hides the fact that it is a
> struct
> beeing handled. If you propose that the only names starting with an uppercase
> letter are structs, then this is kind of consistent in itself if you k
Dimitris Papastamos wrote:
> As long as typedef is used sensible I am ok with the proposed naming
> convention.
Heyho,
for structs I hate to use a typedef since it hides the fact that it is a struct
beeing handled. If you propose that the only names starting with an uppercase
letter are structs,
On 19 November 2014 15:02, Dimitris Papastamos wrote:
> On Wed, Nov 19, 2014 at 02:21:30PM +0100, Anselm R Garbe wrote:
>> On 18 November 2014 11:52, Dimitris Papastamos wrote:
>> >> no block for single statement (optional block? always block? discuss)
>> > LICENSE header
>> > headers
>> > macros
On Wed, Nov 19, 2014 at 02:21:30PM +0100, Anselm R Garbe wrote:
> >> types
> >> =
> >> user defined types start with a capital letter
> >> when possible typedef struct {} Name;
> >
> > Debatable. I'd like to hear more opinions on this.
>
> In most suckless code types always start with capital
On Wed, Nov 19, 2014 at 02:21:30PM +0100, Anselm R Garbe wrote:
> On 18 November 2014 11:52, Dimitris Papastamos wrote:
> >> no block for single statement (optional block? always block? discuss)
> > LICENSE header
> > headers
> > macros
> > types
> > function declarations
> > global vars
> > usage
Hi there,
first of all good effort. I'd like you to bring this style guide
forward to become the official suckless styleguide, not just sbase.
On 18 November 2014 11:52, Dimitris Papastamos wrote:
>> no block for single statement (optional block? always block? discuss)
> LICENSE header
> headers
On Mon, Nov 17, 2014 at 10:47:31PM +0100, FRIGN wrote:
> On Mon, 17 Nov 2014 13:24:21 -0800
> Evan Gates wrote:
> > blocks
> > ==
> > all variable declarations at top of block
Why? In general I prefer declarations to be in the closest to the actual
usage (in the inner most scope).
> > stati
On 18/11/2014, Louis Santillan wrote:
> Returning error code doesn't work well for many asynchronous calls (aio_*)
> [0].
Why? aio_error indeed returns an error code, and separate aio_return
and aio_error would not even be needed if read, write, etc returned as
I proposed, as one call could so r
Returning error code doesn't work well for many asynchronous calls
(aio_*) [0]. It also makes errno (possibly) inconsistent, but I
didn't come up with that standard. I guess someone decided that
making errno inconsistent is less of an issue than make the return
code of libc inconsistent.
[0]
ht
On Tue, Nov 18, 2014 at 11:35:04AM -0500, M Farkas-Dyck wrote:
> On 18/11/2014, Dimitris Papastamos wrote:
> > On a side note here, for a failing syscall or similar, I think the
> > idea is to check for < 0 rather than == -1. I am not opposed to the
> > latter except that is already used less fre
On 18/11/2014, Dimitris Papastamos wrote:
> On a side note here, for a failing syscall or similar, I think the
> idea is to check for < 0 rather than == -1. I am not opposed to the
> latter except that is already used less frequently in sbase.
On an edge note, it would be much saner for many sys
On Tue, Nov 18, 2014 at 09:53:33AM -0500, Greg Reagle wrote:
> Another way to provide style guidance is to refer to a particular source
> file or project as an epitome or paragon, if such a paragon exists That
> takes much less time than explicitly developing a style guide.
Yes my initial idea is
Another way to provide style guidance is to refer to a particular source
file or project as an epitome or paragon, if such a paragon exists That
takes much less time than explicitly developing a style guide.
--
http://www.fastmail.com - Does exactly what it says on the tin
Just a general remark on style guides.
The guide should be followed for all submissions but deviation
is allowed as long as it can be justified or it is clear that
it makes sense.
Given that getting sbase to the point of usability is a difficult
and time consuming task especially with the existin
> no block for single statement (optional block? always block? discuss)
It depends. The following are valid.
if (v) {
bla;
} else {
bla;
bla;
}
if (v) {
bla;
bla;
} else {
bla;
}
if (v)
bla;
else
bla;
The following are invalid.
On Mon, Nov 17, 2014 at 11:18:36PM +0100, FRIGN wrote:
> On Mon, 17 Nov 2014 14:10:49 -0800
> Bobby Powers wrote:
>
> > By default I read if (!functioncall()) as 'if the function call
> > failed'. I like the (strcmp(p, q) == 0) idiom because I don't fall
> > into the trap of reading the stateme
On Tue, Nov 18, 2014 at 02:04:30AM +0100, koneu wrote:
> Hi,
>
> FRIGN wrote:
> > If headers depend on order, the headers are broken. Dismissed.
>
> Most headers I write are plan9 style[0] headers. "The files are not
> protected against multiple inclusion and themselves contain no nested
> #inclu
On Mon, Nov 17, 2014 at 10:47:31PM +0100, FRIGN wrote:
> > headers
> > ===
> > system headers (#include <...>) in alphabetical order
> > empty line
> > local headers (#include "...") in alphabetical order
> > if there is any reason to change order, comment to explain
>
> If headers depend on o
Hi,
FRIGN wrote:
> If headers depend on order, the headers are broken. Dismissed.
Most headers I write are plan9 style[0] headers. "The files are not
protected against multiple inclusion and themselves contain no nested
#includes. Instead the programmer is expected to sort out the
requirements an
> On Mon, 17 Nov 2014 13:24:21 -0800 Evan Gates wrote:
> > headers
> > ===
> > system headers (#include <...>) in alphabetical order
> > empty line
> > local headers (#include "...") in alphabetical order
> > if there is any reason to change order, comment to explain
>
On Mon, Nov 17, 2014 at
On Mon, 17 Nov 2014 14:10:49 -0800
Bobby Powers wrote:
> By default I read if (!functioncall()) as 'if the function call
> failed'. I like the (strcmp(p, q) == 0) idiom because I don't fall
> into the trap of reading the statement as 'if the string comparison
> failed'. It is the one case I ca
On Mon, Nov 17, 2014 at 1:47 PM, FRIGN wrote:
> I must honestly say that you gotta work on your coding style a bit better.
> I spent all evening yesterday and some hours this afternoon to untangle
> your expr.c. It wasn't too bad, but for instance, you had unnecessary
> global variables, unsafe po
Hello,
FRIGN wrote:
>> tests (boolean)
>> ===
>> do not test against NULL explicitly (e.g. if (!p) instead of if (p ==
>> NULL))
>> do not test against 0 explicitly (e.g. if (!strcmp(p, q)) instead of
>> if (strcmp(p, q) == 0)) (discuss)
>
> Yes, yes, yes. See the patches I sent i
On Mon, 17 Nov 2014 13:24:21 -0800
Evan Gates wrote:
Hey Evan,
> sbase has no unified style. Many things change from file to file. I am
> more annoyed by this than I should be. I propose a style document for
> sbase. I have included a starting point in order to promote
> discussion. You will dis
sbase has no unified style. Many things change from file to file. I am
more annoyed by this than I should be. I propose a style document for
sbase. I have included a starting point in order to promote
discussion. You will disagree with some of these points. Speak up and
explain your alternative and
44 matches
Mail list logo
