This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
When libc is configured for the hurd with libio, including <endian.h> and <stdio.h> and <netinet/in.h> does not result in including <sys/types.h> (only <bits/types.h>) and so u_int32_t (vs uint32_t) is not defined and so the htontest.c test program did not compile until I made it get <sys/types.h>. Is this a good thing or a bad thing? On Linux, somehow or other it winds up including <sys/types.h> and defining those types and so there is no problem. Should u_int32_t be guaranteed to be defined by one of those other headers?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |