Hacker News Reader

Comment by wrl | Hacker News Reader

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

View on HN

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

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").

'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

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.)

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.

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

It's an old gcc extension. Don't use it.

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).

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.

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.

> If it's a kernel module, then you'd be silly not to use the gcc extension.

Sure, if you're not interested in anyone porting that code to another OS. This happens all the time with drivers -- just because the interface is OS-specific doesn't mean all the code is.

> And those extensions are there because someone likes them.

That doesn't make it a good idea.

Extensions have occasionally been dropped from gcc, sometimes because of conflicts with updated standards, sometimes for other reasons.

Reply on news.ycombinator.com