Date: Wed, 28 Nov 2012 19:11:23 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Martin Sustrik <sustrik@250bpm.com> Cc: freebsd-bugs@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: Possible non-conformance to POSIX Message-ID: <20121128183903.H2965@besplex.bde.org> In-Reply-To: <50B5B2F7.9050801@250bpm.com> References: <50B53938.2010601@250bpm.com> <20121128092318.U1509@besplex.bde.org> <50B59F3D.5030102@250bpm.com> <50B5B2F7.9050801@250bpm.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Nov 2012, Martin Sustrik wrote:
> On 28/11/12 06:21, Martin Sustrik wrote:
>> On 27/11/12 23:39, Bruce Evans wrote:
>>
>>>> #include <netinet/in.h>
>>>> INADDR_ANY;
>>>>
>>>> The above results in 'u_int32_t undefined' error, which it shouldn't
>>>> according to POSIX.
>>>
>>> <netinet/in.h> is careful to only declare uint32_t, but then it is
>>> broken and uses u_int32_t for INADDR_ANY and INADDR_BROADCAST.
>>> ...
>>
>> Yes. I figured out that including <sys/types.h> solves the problem. I
>> was just pointing out the bug.
>>
>> If there's interest I can send a patch for INADDR_ANY and INADDR_BROADCAST.
You should file a PR since I'm not into that or committing a fix for this :-).
> I should also add that the problem is important because of feature checking
> in different build tools. The tool usually checks the existence of a symbol
> by trying to compile something like this:
>
> #include <netinet/in.h>
> INADDR_ANY;
> int main () {return 0;}
>
> If the compilation fails, it assumes the symbol is not defined. Which in not
> true in this context.
>
> Btw, I've found another similar problem. Trying to compile the following:
>
> #include <getifaddrs.h>
<ifaddrs.h>
> int main () {return 0;}
>
> results in:
> /usr/include/ifaddrs.h:34: error: expected specifier-qualifier-list before
> 'u_int'
>
> Which, of course, means that the build tool (CMake in this case) reports that
> getifaddrs.h file is not available on FreeBSD platform.
Now the header is non-POSIX, and <sys/types.h> and also <sys/socket.h>
are documented (in getifaddrs(3)) prerequisites for using it, so the
bug is mostly in the build tool.
<sys/types.h> is certainly required (bogusly, for this single u_int).
It used to be required for <sys/socket.h>
(bogusly, since <sys/socket.h> is not required for the functions
declared <ifaddrs.h> in but only for dereferencing some of the
pointers in the data structures; it is documented that <net/if.h>
is needed for other uses of the pointers, but this is correctly left
out of the synopsis),
but <sys/socket.h> has been updated so it no longer requires <sys/types.h>.
It is also documented in the BUGS section that "If both <net/if.h> and
<ifaddrs.h> are being included, <net/if.h> _must_ be included before
<ifaddrs.h>". This is wrong too. <net/if.h> hasn't been cleaned up much,
but cleanups (or just anti-reinclusion guards) in other headers apparently
made the bug go away. <net/if.h> itself has actually been polluted more.
In 4.4BSD-Lite1, it was polluted by including <sys/time.h>, but with an ifdef
for this and a comment saying that this is a quick fix for SNMP and is going
away soon. 19 years later is not soon of course, so the pollution is still
there, and only the comment about it going away has gone away (been modified),
and the pollution has been extended to <sys/socket.h> in userland and much
further to <net/if_var.h> in the kernel.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121128183903.H2965>