Re: >/usr/include/arpa/inet.h:67: conflicting types for `htons' (fwd)

[Jeffrey A Law <law at cygnus dot com>]

  In message <19990629082232.Y1215@rjlhome.sco.com>you write:
  > > I'm also very leery of just zapping prototypes.  That's bad.
  > 
  > Ordinarily I'd agree.   Perhaps my rationale wasn't clear.
  > 
  > Byteswapping for networking working code is worth optimizing.  Both
  > GCC and the native compiler agree on this.  GCC installs its own
  > <sys/byteorder.h> to do the highly optimized asm() thing.  The native
  > compiler (and therefore the native system headers) does the same thing.
  > 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.  

Of course it is safe if inet.h unconditionally includes 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.

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.

jeff