This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: >/usr/include/arpa/inet.h:67: conflicting types for `htons' (fwd)
- To: Jeffrey A Law <law at cygnus dot com>
- Subject: Re: >/usr/include/arpa/inet.h:67: conflicting types for `htons' (fwd)
- From: Robert Lipe <robertlipe at usa dot net>
- Date: Thu, 1 Jul 1999 09:54:38 -0500
- Cc: David Coder <dacoder at dcoder dot com>, tangent at cyberport dot net, egcs at egcs dot cygnus dot com
- References: <19990629082232.Y1215@rjlhome.sco.com> <28156.930816425@upchuck.cygnus.com>
> > The underlying problem is a collision between the two. Since only
> > GCC will see the fixed headers, I just whacked the conflicting
> > protos for the native ones.
>
> But if someone includes inet.h without byteorder.h (is that possible?)
> expecting to get prototypes for those functions then they're going to
> lose. That's why I worry about zapping prototypes.
You're wise to worry about it.
> Of course it is safe if inet.h unconditionally includes byteorder.h.
I believe this to be safe for that very reason. I could bore you with
the unconditional "proof" that led me to that conclusion, but it does
indeed include it.
$ cat /tmp/x.c
#include <arpa/inet.h>
(robertl) rjludi:/tmp
$ gcc -M /tmp/x.c | grep byteorder
/usr/local/lib/gcc-lib/i686-UnixWare7.0.1-sysv5/egcs-2.91.61/include/sys/byteorder.h \
> But if it doesn't, then we need to look for a better fix. One might
> be to replace existing prototypes in inet.h with gcc's prototypes.
If that's necessary I can do that.
> Another might be to conditionalize the inet.h prototypes if there
> is something we can use to determine if we have already included
> byteorder.h.
I tried to avoid that for fear of taunting the default argument
promotion rules.
RJL