3 ms·

Array initializer syntax, particularly with ranges. static cmd_handler_t handlers[16] = { [0 ... 15] = handler_noop, [1] = handler_for_1,

by wrl 15y ago

Array initializer syntax, particularly with ranges. static cmd_handler_t handlers[16] = { [0 ... 15] = handler_noop, [1] = handler_for_1, [3] = handler_for_3, [6 ... 8] = handler_for_6_through_8 }; And suchforth. Very natural for parsers. Particularly nifty is Jaremie Miller's js0n parser, which makes heavy use of this: https://github.com/quartzjer/js0n/blob/master/js0n.c https://github.com/quartzjer/js0n/blob/master/js0n.c

mansr 15y ago
Range initialisers are a gcc extension. They should not be used in portable code.
- tptacek 15y ago
  Any time I have ever, ever used a gcc extension in my own code, I have always been sorry for having done so later --- usually more than a year later, at a moment when I don't really have time budgeted for being sorry about binding my code directly to gcc. (I see a difference between literally using GCC-dialect C and relying on dubious C constructs that happen to work well on C; for instance, I've never been bitten by "extern inline").
  - mansr 15y ago
    I have run into errors caused by weird uses of inline, I think it was with the MIPSpro compiler, in code happily swallowed by gcc.
  - brigade 15y ago
    'extern inline' isn't a dubious C99 construct; it's well defined what it means. The problem is that the 'extern inline' gcc extension means something else, and is enabled by default unless you specify -std=c99
  - JoachimSchipper 15y ago
    I agree your code should not depend on GCC, but stuff like __attribute__((nonnull(1), format(printf, 3, 4))) - "the first argument may not be NULL, the third argument is a printf()-style format string with arguments starting after the fourth element" - can produce some useful warnings and can be trivially disabled on non-GCC compilers. Some of the most useful extensions don't lock you into GCC. (Now, if only Microsoft would get off their asses and make their compiler C99-compliant, we could all write much nicer code.)
tptacek 15y ago
When did we get the ellipsis in the named array initializer syntax? That's standard? Neat.
- mansr 15y ago
  It's an old gcc extension. Don't use it.
  - ajross 15y ago
    It's a very useful gcc extension. Use if if you're building with gcc. Standards adherence is all well and good, but there are many problem areas where you can rely on a single compiler (surely others support it too: intel and clang seem like likely suspects).
    - tptacek 15y ago
      There are standards issues and there are standard issues. In reality, you're probably never going to see a 1's complement machine. Your likelihood of needing to use a piece of code under a compiler other than GCC is deceptively high. Meanwhile, the extensions we tend to think about when we think of GCC aren't subtle things like "can you use // comments in C code". They're constructs that require many additional lines of code to replace. It is a giant pain when you find them, later on, when you need to compile something under Visual C or SunWorks. Your fix to comment syntax isn't going to break code at runtime, but your fix for the missing ellipsis operator definitely can! From bitter experience, I think 'mansr is right on this, and it's worth making an effort not to let GCC extensions creep into your code.
      - ajross 15y ago
        But like I said, it depends on what the code is. If it's a kernel module, then you'd be silly not to use the gcc extension. Likewise if it's a platform-locked linux or mac thing (Android middleware, maybe). You work in security, where you're expected to port stuff between platforms regularly. Not everyone does. And those extensions are there because someone likes them.

by wrl 15y ago

mansr 15y ago

Range initialisers are a gcc extension. They should not be used in portable code.

tptacek 15y ago
Any time I have ever, ever used a gcc extension in my own code, I have always been sorry for having done so later --- usually more than a year later, at a moment when I don't really have time budgeted for being sorry about binding my code directly to gcc. (I see a difference between literally using GCC-dialect C and relying on dubious C constructs that happen to work well on C; for instance, I've never been bitten by "extern inline").
- mansr 15y ago
  I have run into errors caused by weird uses of inline, I think it was with the MIPSpro compiler, in code happily swallowed by gcc.
- brigade 15y ago
  'extern inline' isn't a dubious C99 construct; it's well defined what it means. The problem is that the 'extern inline' gcc extension means something else, and is enabled by default unless you specify -std=c99
- JoachimSchipper 15y ago
  I agree your code should not depend on GCC, but stuff like __attribute__((nonnull(1), format(printf, 3, 4))) - "the first argument may not be NULL, the third argument is a printf()-style format string with arguments starting after the fourth element" - can produce some useful warnings and can be trivially disabled on non-GCC compilers. Some of the most useful extensions don't lock you into GCC. (Now, if only Microsoft would get off their asses and make their compiler C99-compliant, we could all write much nicer code.)

tptacek 15y ago

When did we get the ellipsis in the named array initializer syntax? That's standard? Neat.

mansr 15y ago
It's an old gcc extension. Don't use it.
- ajross 15y ago
  It's a very useful gcc extension. Use if if you're building with gcc. Standards adherence is all well and good, but there are many problem areas where you can rely on a single compiler (surely others support it too: intel and clang seem like likely suspects).
  - tptacek 15y ago
    There are standards issues and there are standard issues. In reality, you're probably never going to see a 1's complement machine. Your likelihood of needing to use a piece of code under a compiler other than GCC is deceptively high. Meanwhile, the extensions we tend to think about when we think of GCC aren't subtle things like "can you use // comments in C code". They're constructs that require many additional lines of code to replace. It is a giant pain when you find them, later on, when you need to compile something under Visual C or SunWorks. Your fix to comment syntax isn't going to break code at runtime, but your fix for the missing ellipsis operator definitely can! From bitter experience, I think 'mansr is right on this, and it's worth making an effort not to let GCC extensions creep into your code.
    - ajross 15y ago
      But like I said, it depends on what the code is. If it's a kernel module, then you'd be silly not to use the gcc extension. Likewise if it's a platform-locked linux or mac thing (Android middleware, maybe). You work in security, where you're expected to port stuff between platforms regularly. Not everyone does. And those extensions are there because someone likes them.