Sylvain Beucler <[EMAIL PROTECTED]> writes: > On Sun, Dec 07, 2008 at 04:11:34PM -0800, Ben Pfaff wrote: >> Brian Dessent <[EMAIL PROTECTED]> writes: >> >> > MinGW implements access to 'environ' as a macro in stdlib.h, one which >> > gets the environment pointer through a function call. However, that >> > macro is not enabled if __STRICT_ANSI__ is set, and -std=c99 sets >> > __STRICT_ANSI__. So one workaround would be to drop -std=c99, or add >> > -U__STRICT_ANSI__ to CFLAGS but that seems rather lame. >> >> Is there a particular reason that you want to use -std=c99? To >> me, it seems odd to request C99-only semantics from the compiler >> and then try to use features that are not part of C99 >> (e.g. environ). >> >> I would use -std=gnu99 in this case. > > I'm not sure if you're asking Brian or I, but I can answer for me. > > I'm using C99 because that's the version I decided to use - it's a > standard, it's more convenient to use than C89, and it's old enough to > use it for my purposes. I'm have some fear, uncertainty and doubt > about 'gnu99' which lacks the 'standard' part. > > Then I'm using putenv, which in itself shouldn't be a problem as long > as I'm under a POSIX system, or using the gnulib replacement. However > the replacement depends on non-C99 feature. In which case I can: > > a. bug the gnulib team into supporting C99 in this particular case :) > > b. drop C99 > > c. switch back to not using the 'putenv' module, which happens to work > in the platforms I'm currently supporting - so no big deal. > > I chose c. but I'm glad I got the explanation from a. :)
Maybe you could disable C99 in the gnulib directory? /Simon
