bug-gnulib
[Top][All Lists]
Advanced

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

Re: EX_OK collision


From: Simon Josefsson
Subject: Re: EX_OK collision
Date: Sun, 01 Apr 2007 11:26:35 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux)

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> Possibly the bug-workaround for unistd.h should only be enabled if the
>> sysexits module is present, otherwise the unistd-module would always
>> touch non-standardized namespaces which seems wrong.
>
> I agree.  I'd rather not use the sysexits module, which means I'd
> rather not have the unistd module messing with EX_OK (for example,
> lib/euidaccess.c or similar code may need the system unistd.h EX_OK).

Right.

>> e) Create a replacement <unistd.h> that does:
>>
>>    #include </usr/include/unistd.h>
>>    #if @GNULIB_SYSEXITS@
>>    #  undef EX_OK
>>    #endif
>
> That doesn't look right, since code would have to include unistd.h
> before sysexits.h.
>
> How about (b)?  It seems the simplest.
>
>>   (b) Create a replacement <sysexits.h> that does
>>
>>          #include <unistd.h>
>>          #undef EX_OK
>>          #include </usr/include/sysexits.h>

Yes, I think so too.  That may cause problems if someone is using
EX_OK without using the sysexits module with a buggy unistd, but they
should really be using the sysexits module then.  Most likely, using
EX_OK without the sysexits module will break on some other platforms,
and then they will start using that module.

Perhaps a 'gnulib-lint' could be useful?  The tool would search your
code for non-portable function usages and suggest names of gnulib
modules that you'll need.  If it finds EX_OK in your code, it would
suggest adding the sysexits module.

/Simon




reply via email to

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