Long term, gcc extensions mean a given piece of code will only be
compilable by gcc. If the extension is succesful enough, it may
even be adopted by other compilers, such as Intel CC. Happened
in the past.

Personally, I tend to not like gcc extensions. Especially the silent
variety. Now that the C language is reasonably normalized, staying
away from extensions is a good idea. Or knowing what you do.

There are *tons* of clueless people out there writing code... clueless
when it comes to portability, because they might be geniuses in their
own domain. For instance, I just stumbled on the following FAQ entry:

Q. On RedHat Linux 7.* I got the following error on compilation of toolkit:
[...]
../lib/libncbi.a(ncbifile.o): In function `Nlm_TmpNam':
ncbifile.o(.text+0x728): the use of `tempnam' is dangerous, better use
`mkstemp'
collect2: ld returned 1 exit status
make: *** [Psequin] Error 1
FAILURE primary make status = 0, demo = 0, threaded_demo = 0, net = 2

A. The problem is that you probably have the 'openmotif-devel' RPM installed,
   which provides a 'libXm.a' that defines that function. We don't build
   the toolkit aganist Open Motif, we build it against Lesstif. If the
   end-user removes the 'openmotif-devel' package, things should work.
   (The user might have to install a lesstif package or two, depending
   on what they've already got set up.)

   Why RedHat lets you install two different Motif toolkits at the same
   time, when they don't have identical implementations, is beyond us.

priceless, isn't it ? and the build system the people behind blast have
developed is shockingly different too (csh scripting anyone ?)

Well, the more non-standard stuff there is that isn't obviously
non-standard, the more `fun' issues along these lines we'll get...

I spend enough time already, when I wear my OpenBSD porter cap, porting
linux-only, i386-centric stuff that depends on gcc, gnu-make, bash
stuff and still claims to be Unix (#include <values.h>, yeah right...
%.o: %.c, yeah right too)


Personally, I would even say that it would be *great* if gcc would start
warning if you use any extension, unless you explicitly disable those
warnings... (except for __extension__ in header files, and then I've
stumbled upon situations where it hurts still).

Reply via email to