Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plan 9 Coding Conventions for C

plan9.bell-labs.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: Plan 9 Coding Conventions for C

#11

Post by _pmf_ »

jstanley wrote: post #5
peteretep wrote: post #3

eg: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/ramfs.c

Anybody know what the: int needfid[] = { [Tversion] 0, [Tflush] 0, [Tauth] 0, syntax means? Is this some Plan 9 extension, or is it just something I've never encountered? EDIT: I guess the value in the []'s is the array index to set the value of.

> Is this some Plan 9 extension, or is it just something I've never encountered?

It's C99 (I also only saw it in C99 articles, never in production code). See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Designated-Inits...

Re: Plan 9 Coding Conventions for C

#12

Post by jacobparker »

shin_lao wrote: post #2

I appreciate that these are old rules, nevertheless, I have the following comments: don't use // comments; some old Plan 9 code does, but we're converting it as we touch it. We do sometimes use // to comment–out a few lines of code. Doesn't make sense with any decent editor, you ought to comment via macros. no braces around single–line blocks (e.g., if, for, and while bodies) I kind of like enforcing the opposite (al…

And don't forget:

    if(a)
        if(b)
            x;
    else
        y;
This doesn't do what the indentation implies. (http://en.wikipedia.org/wiki/Dangling_else)

Walter Bright (creator of D, etc.) has an article where he discusses his interesting choice to make that grammar form illegal in D. He mentions that after doing this he found a bug in D's runtime library. http://www.drdobbs.com/cpp/dangling-else-yet-again/231602010

Re: Plan 9 Coding Conventions for C

#13

Post by pdw »

jstanley wrote: post #5
peteretep wrote: post #3

eg: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/ramfs.c

Anybody know what the: int needfid[] = { [Tversion] 0, [Tflush] 0, [Tauth] 0, syntax means? Is this some Plan 9 extension, or is it just something I've never encountered? EDIT: I guess the value in the []'s is the array index to set the value of.

A variation of this syntax was standardized in C99:

    int needfid[] = {
        [Tversion] = 0,
        [Tflush] = 0,
It works for structs too:

    struct blah needfid = {
        .version = 0,
        .flush = 0,

Re: Plan 9 Coding Conventions for C

#14

Post by pdw »

_pmf_ wrote: post #11
jstanley wrote: post #5

Earlier quoted context omitted.

Anybody know what the: int needfid[] = { [Tversion] 0, [Tflush] 0, [Tauth] 0, syntax means? Is this some Plan 9 extension, or is it just something I've never encountered? EDIT: I guess the value in the []'s is the array index to set the value of.

> Is this some Plan 9 extension, or is it just something I've never encountered? It's C99 (I also only saw it in C99 articles, never in production code). See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Designated-Inits...

It's heavily used in the Linux kernel and in the Linux world in general. But Visual Studio doesn't support it, so projects that target Windows pretty much have to avoid it.

Re: Plan 9 Coding Conventions for C

#15

Post by glurgh »

jstanley wrote: post #5
peteretep wrote: post #3

eg: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/ramfs.c

Anybody know what the: int needfid[] = { [Tversion] 0, [Tflush] 0, [Tauth] 0, syntax means? Is this some Plan 9 extension, or is it just something I've never encountered? EDIT: I guess the value in the []'s is the array index to set the value of.

That's right, it's a designated initializer, except the standard c99 way requires an =. gcc didn't/doesn't but that's nonstandard. So it is an extension, just not a plan9 one - a gcc-ism. clang's error/warning, as usual, is very helpful so it's worth it just to try clang when running into weirdness like that:

    warning: use of GNU 'missing =' extension in designator
          [-Wgnu-designator]

Re: Plan 9 Coding Conventions for C

#16

Post by nteon »

shin_lao wrote: post #2

I appreciate that these are old rules, nevertheless, I have the following comments: don't use // comments; some old Plan 9 code does, but we're converting it as we touch it. We do sometimes use // to comment–out a few lines of code. Doesn't make sense with any decent editor, you ought to comment via macros. no braces around single–line blocks (e.g., if, for, and while bodies) I kind of like enforcing the opposite (al…

I can't stand macro comments - it makes it impossible to figure out whats going on without being sure to open the file in a specific editor with a specific project loaded. Say you have a separate lib project used by an application - if you open up an individual file from that lib while working on the application in Visual Studio it won't have the necessary context to 'comment out' macro comments. Its also hostile to people who use vi and emacs.

Re: Plan 9 Coding Conventions for C

#17

Post by shin_lao »

gosu wrote: post #6
shin_lao wrote: post #2

I appreciate that these are old rules, nevertheless, I have the following comments: don't use // comments; some old Plan 9 code does, but we're converting it as we touch it. We do sometimes use // to comment–out a few lines of code. Doesn't make sense with any decent editor, you ought to comment via macros. no braces around single–line blocks (e.g., if, for, and while bodies) I kind of like enforcing the opposite (al…

OS code has to do a lot of validating input and braceful style causes functions to be visually dominated by boring validation code. It's also surprisingly nice to have a visual distinction between boring conditions like if(!found) return; and the more interesting branches that require the braces. Not sure I follow you on the one; two; example. Why would you have two statements per line in the first place? (You do rea…

Because developer one wrote

if (statement) one;

And developper two added

if (statement) one; two;

too quickly

Re: Plan 9 Coding Conventions for C

#18

Post by shared4you » 

     >  no white space after the keywords if, for, while, etc.
Woh, my workplace enforces the exact opposite! The idea is that if, while, etc are not functions, therefore `if (x)` is unacceptable but `my_func(x)` is ok. I personally prefer `if(x)` though.

Re: Plan 9 Coding Conventions for C

#20

Post by jomar »

shin_lao wrote: post #17
gosu wrote: post #6

Earlier quoted context omitted.

OS code has to do a lot of validating input and braceful style causes functions to be visually dominated by boring validation code. It's also surprisingly nice to have a visual distinction between boring conditions like if(!found) return; and the more interesting branches that require the braces. Not sure I follow you on the one; two; example. Why would you have two statements per line in the first place? (You do rea…

Because developer one wrote if (statement) one; And developper two added if (statement) one; two; too quickly

The actual problem there is that developer two checked something in without thinking about it, reading it, or examining the diffs of the change.

If you had a coding convention of always using braces in if statements, you might be insulated from this particular symptom or instance of the problem, but you still have the underlying problem that people are doing things without thinking.

Post reply on HN