[Top][All Lists]
[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