No. Do not use them.

The problem isn't the extensions themselves. Most of them are pretty
good ideas and all of them are tempting in their own way. Some have
even been copied to an unknown and unpredictable extent by a commercial
compiler or two.

But bad things will happen in the long run and by their very definition
they are non-portable.  For a really good example of why NOT, just look at
the linux kernel. Someone (ahem) has unprofessionally _poured_
gnu-gcc-specific constructs into the linux kernel. Let's back up to the
theoretical reasons why linux should not have done this, and then see what
the actual results have been.

  1. Invariably, the specification for standard features is given in far
     greater detail with far greater clarity and precision.  Expanded
     treatments are written in hundreds or even thousands of publications
     on the subject of C programming. You know exactly how programs will
     behave.

  2. The standard constructs cannot be changed. They are fixed for all time.
     To some extent .. certainly to a greater extent ..  gnu extensions
     can be changed, clarified, "improved", or dropped.  Because they
     are specified more vaguely, the compiler can change in the future
     and still meet the extension spec. This is bad.

  3. As you've noted, it's easier to maintain the standard constructs
     that _should_ be universally understood by all developers. No one
     expects you to know the gcc extensions and there is even an argument
     that you should not.

  4. The extensions are virtually unused in comparison to the standard
     features, and as a result __STDC__ is vastly better tested, and any
     bugs that creep into standard features are quickly found. There are
     uncounted millions of lines of standard feature code out there. There
     aren't many lines of code using gnu-gcc-extension features. Bugs that
     exist initially or creep into the extensions can lurk forever.

Now, how has linux done? In general, releases of linux are tied to a specific
gcc release. That speaks volumes to the problems. Looking more closely,
asm statements that violated the rules were used but accepted by older
compilers. Now these statements are producing errors in the new compilers.
Individual linux versions depend on new features, or produce bugs on new,
or sometimes old, compilers. New compilers reject the less-than-perfect
use of extensions that used to compile correctly. It's a bad road to go
down. You can set your clock by Linus flaming the h_ll out of the gcc
developers for no reason. He gets himself in trouble and then gets mad
that the gcc developers won't make him a hacked-up extension or optimization
to solve his latest problem, which was usually created by violating __STDC__
rules or by violating the more vaguely specified extension rules.

We do use gnu features at times. There is a professional way to do this.

  1.  It should be done for a specific functional benefit, not just
      so the code is a little easier to type in.

  2.  The feature should be wrapped in a CPP macro and preferably with
      whatever #if is necessary to test for gcc and the gcc version,
      and to provide an alternate __STD__ implementation, even if it's
      not perfectly equivalent.

  3.  Even if the feature can be used in a totally compatible way,
      the reliability objections remain. Hence it is still necessary to
      wrap the feature in a CPP macro so it can be quickly disabled. See
      __predict_{true,false} in /sys/sys/cdefs.h, and the way it is used
      in the kernel.

Another example of use of a gnu feature is our symbol rename hack. If the
system were ever compiled with some other compiler, compatibility with old
libraries would not be an issue, and we have an alternative implementation.
(Major number bump and/or #ifdef's of compatibility interfaces.)

// ross