From owner-freebsd-standards@FreeBSD.ORG Thu Jun 12 22:24:15 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97199DA; Thu, 12 Jun 2014 22:24:15 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 58AF82FCB; Thu, 12 Jun 2014 22:24:15 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 04F23B806D; Fri, 13 Jun 2014 00:24:12 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id D7D3528497; Fri, 13 Jun 2014 00:24:11 +0200 (CEST) Date: Fri, 13 Jun 2014 00:24:11 +0200 From: Jilles Tjoelker To: Bruce Evans Subject: Re: standards/188316: Visibility of ntohl etc. and POSIX 2008 Message-ID: <20140612222411.GB171@stack.nl> References: <201404061430.s36EUbFE092028@cgiserv.freebsd.org> <20140407024203.M6470@besplex.bde.org> <20140518215050.GA8365@stack.nl> <20140531224728.G1905@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140531224728.G1905@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-gnats-submit@freebsd.org, freebsd-standards@freebsd.org, Christian Neukirchen X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:24:15 -0000 On Sat, May 31, 2014 at 11:35:43PM +1000, Bruce Evans wrote: > I finally got back to this. > On Sun, 18 May 2014, Jilles Tjoelker wrote: > > On Mon, Apr 07, 2014 at 03:43:44AM +1000, Bruce Evans wrote: > >> On Sun, 6 Apr 2014, Christian Neukirchen wrote: > >>>> Fix: > >>> Guard the definition with __POSIX_VISIBLE >= 200112. > >> This is wrong too, and is inconsistent with where there > >> the symbols are defined unconditionally (if this wouldn't be redundant). > >> The correctness of this depends on the symbols being in a header that > >> doesn't exist in versions of POSIX that don't have the symbols. I > > ... > > So you propose to change the "#if !defined(_KERNEL) && __BSD_VISIBLE" > > conditional to "#ifndef _KERNEL"? This affects only old versions of > > POSIX (where may not be included anyway) and non-POSIX > > standard C (which does not define either). > > Note that there are other __POSIX_VISIBLE >= 200112 conditionals in > > , so the submitter's change may be more consistent, even > > if it is somehow wrong. > I see you committed a version that changed to a __POSIX_VISIBLE conditional. > There were only 2 _POSIX_VISIBLE conditionals. They were mostly for > ipv6 things, so removing them won't expose many problematic symbols. > I'm surprised POSIX had so much support for ipv6 in 2001. The ipv6 > extensions are in mostly in netinet6/in6.h. They are fairly carefully > ifdefed, and of course are mostly spelled with a '6' to keep them > separate from ipv4 names (which are mostly not spelled with a '4'). > Unfortunately, their namspace isn't very consistent. POSIX reserves > mainly IP6, IPV6_, IN6_, in6_, s6_ and sin6_ as prefixes, and still > has special cases like sockaddr_in6 and in6addr_any where the '6' is not > part of a prefix or not followed by an underscores. FreeBSD extensions > extend the mess, e.g., by using inet6_ instead of in6_ as a prefix for > most functions. POSIX avoided the corresponding mistake for ipv4 (the > alternative spellings in_ and inet_) for the lower case versions, and > avoided reserving INET6_ as a prefix (it is only used for special cases > like AF_INET6). I guess the _POSIX_VISIBLE conditionals are to allow matching RFC 1700 in strict C standard mode, or for compliance to IEEE 1003.1g-2000 (the socket extension to POSIX.1-1996). Both of these are obsolete, so support could be removed. -- Jilles Tjoelker