bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: putenv with mingw32


From: Sylvain Beucler
Subject: Re: putenv with mingw32
Date: Tue, 9 Dec 2008 00:00:33 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Dec 07, 2008 at 04:11:34PM -0800, Ben Pfaff wrote:
> Brian Dessent <address@hidden> 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. :)

-- 
Sylvain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]