Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2012 09:39:23 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Martin Sustrik <sustrik@250bpm.com>
Cc:        freebsd-bugs@FreeBSD.org
Subject:   Re: Possible non-conformance to POSIX
Message-ID:  <20121128092318.U1509@besplex.bde.org>
In-Reply-To: <50B53938.2010601@250bpm.com>
References:  <50B53938.2010601@250bpm.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Nov 2012, Martin Sustrik wrote:

> I've just noted the following:
>
> #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.
u_int32_t is also misused extensively in the definitions of INADDR_*
and IN_* under __BSD_VISIBLE.  INADDR_ANY is broken even if __BSD_VISIBLE
is nonzero (the default), because the u_int32_t pollution is not
automatically supplied with __BSD_VISIBLE.  It takes including
<sys/types.h> (with __BSD_VISIBLE) to get it.

Nearby bugs: missing parentheses in the definitions of INADDR_ANY and
INADDR_BROADCAST.  Similarly for definitions under __BSD_VISIBLE.
Casts bind tightly (they are at the second level of precedence --
see `man operator'), so it takes very weird usage for these bugs
to matter.

Nearby style bugs: some of the not-so-extensive use of uint32_t is
probably a misspelling of in_addr_t.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121128092318.U1509>