From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 28 08:18:04 2012 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D253A20 for ; Wed, 28 Nov 2012 08:18:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 3C58B8FC12 for ; Wed, 28 Nov 2012 08:18:02 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAS8BfrX024426 for ; Wed, 28 Nov 2012 19:11:41 +1100 Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAS8BOF9026118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2012 19:11:27 +1100 Date: Wed, 28 Nov 2012 19:11:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Sustrik Subject: Re: Possible non-conformance to POSIX In-Reply-To: <50B5B2F7.9050801@250bpm.com> Message-ID: <20121128183903.H2965@besplex.bde.org> References: <50B53938.2010601@250bpm.com> <20121128092318.U1509@besplex.bde.org> <50B59F3D.5030102@250bpm.com> <50B5B2F7.9050801@250bpm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=CatQf8Xl c=1 sm=1 a=dD6fYmnc2FAA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=SOV9EjKwEXAA:10 a=9pvNbUSvFgCqenSkzBwA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-bugs@FreeBSD.org, Bruce Evans X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 08:18:04 -0000 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 >>>> INADDR_ANY; >>>> >>>> The above results in 'u_int32_t undefined' error, which it shouldn't >>>> according to POSIX. >>> >>> 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 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 > 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 > 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 and also are documented (in getifaddrs(3)) prerequisites for using it, so the bug is mostly in the build tool. is certainly required (bogusly, for this single u_int). It used to be required for (bogusly, since is not required for the functions declared in but only for dereferencing some of the pointers in the data structures; it is documented that is needed for other uses of the pointers, but this is correctly left out of the synopsis), but has been updated so it no longer requires . It is also documented in the BUGS section that "If both and are being included, _must_ be included before ". This is wrong too. hasn't been cleaned up much, but cleanups (or just anti-reinclusion guards) in other headers apparently made the bug go away. itself has actually been polluted more. In 4.4BSD-Lite1, it was polluted by including , 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 in userland and much further to in the kernel. Bruce