bug-gnulib
[Top][All Lists]
Advanced

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

Re: rpl_close replaces struct members named 'close'


From: Sylvain Beucler
Subject: Re: rpl_close replaces struct members named 'close'
Date: Sun, 23 Dec 2007 09:32:08 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

On Sat, Dec 22, 2007 at 06:35:30PM -0800, Paul Eggert wrote:
> Sylvain Beucler <address@hidden> writes:
> 
> > unistd.in.h replaces 'close' by 'rpl_close' (when the replacement is
> > enabled), so this also renames the struct member.
> 
> Is that a real problem?  Why does it matter what the struct member is
> called, so long as the program always calls it by the same name?

I didn't think of that :)


> I'm asking because, if this is a problem with gnulib, it is likely a
> problem with other platforms like Solaris, which are not above putting
> things like "#define open open64" in their standard header files.


I think this makes it difficult to order the #include statements
correctly.

For example, in my code:
 #include <string.h> /* strchr */
 #include <SDL_rwops.h>
 #include <zzip/zzip.h>
 ...
 rwops->close = rwops_zzip_close;
does not replace close->rpl_close in <SDL_rwops.h>, while
 #include <string.h> /* strchr */
 #include <zzip/zzip.h>
 #include <SDL_rwops.h>
 ...
 rwops->close = rwops_zzip_close;
does.

("rwops->close = ..." is always replaced)
(string.h is from gnulib too)

<zzip/zzip.h> calls some headers (fcntl.h maybe?) that trigger
close->rpl_close, while <string.h> does not.


I see it as a problem because I cannot spot this kind of issue until I
(cross-)compile on the impacted platform, and the fix is not obvious.
I could live with it, though.

-- 
Sylvain




reply via email to

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