bug-gnulib
[Top][All Lists]
Advanced

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

Re: putenv with mingw32


From: Simon Josefsson
Subject: Re: putenv with mingw32
Date: Tue, 09 Dec 2008 08:24:09 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

Sylvain Beucler <address@hidden> writes:

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

Maybe you could disable C99 in the gnulib directory?

/Simon





reply via email to

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