On Thursday, December 24, 2020 at 9:04:00 AM UTC-8, Kaz Kylheku wrote:
Post by Kaz Kylheku
"The <netdb.h> header may define the in_port_t type and the in_addr_t
type as described in <netinet/in.h>."
It specifically doesn't say "<netdb.h> is free to define struct in_addr
and other random stuff from <netinet/in.h>". Only specific redundancy is
allowed between headers.
True, though for several of them the allowed redundancy is complete. If you scroll further down on that netdb.h.html page, you'll find this text:
"Inclusion of the <netdb.h> header may also make visible all symbols
from <netinet/in.h>, <sys/socket.h>, and <inttypes.h>."
However, if we go back to your original report, it's that "There were errors about types like in_addr not being defined." If they weren't defined, then _none_ of the headers that are required to provide them were included. So it's not just that, say, <netdb.h> was #included while <netinet/in.h> wasn't, because <netdb.h> is also required to provide in_addr_t.
So, if the headers of both systems are actually being used in a POSIX conforming mode (e.g., correct compiler flags), then this should not of occurred. But it did. That suggests one or both is not actually being used in a conforming mode.
On glibc systems, <features.h> has a long comment describing which pre-processor symbols enable various modes of compliance. After going through which do what, it has this statement:
"If none of these are defined, the default is to have _SVID_SOURCE,
_BSD_SOURCE, and _POSIX_SOURCE set to one and _POSIX_C_SOURCE set to
_SVID_SOURCE and _BSD_SOURCE enable headers features which are not POSIX compliant, possibly pulling in <netinet/in.h> where POSIX wouldn't permit.
Most likely, however, is that the application itself isn't actually POSIX compliant, using headers which are neither defined by POSIX nor provided by the application, which puts it at the mercy of the system. For example, the glibc <resolv.h> pulls in <netinet/in.h> but at least some BSD-derived versions do _not_, requiring the application to pull it before including <resolv.h>.
The easiest way to track this down is probably to take the file which fails to compile on bionic, and compile it on Linux but passing the compiler the -dD -E options instead of -c, so you can see exactly what is being defined or provided where and trace back what is pulling in <netinet/in.h>
The 'solution' is almost guaranteed to be "just add #include <netinet/in.h> to the code" but I'm 100% on-board with understanding _how_ this non-portability occurs, so that it's easier to prevent and fix in the future.