From owner-freebsd-standards@freebsd.org Sat Jan 30 17:24:22 2016 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09CDEA73757 for ; Sat, 30 Jan 2016 17:24:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (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 C7B9B1394; Sat, 30 Jan 2016 17:24:18 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mx1.stack.nl (Postfix) with ESMTP id 3EBE83592E8; Sat, 30 Jan 2016 18:24:15 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 38605892B6; Sat, 30 Jan 2016 18:24:15 +0100 (CET) Date: Sat, 30 Jan 2016 18:24:15 +0100 From: Jilles Tjoelker To: Matthias Andree Cc: freebsd-standards@FreeBSD.org Subject: Re: __STRICT_ANSI__, __BSD_VISIBLE (cc -std=c99) vs. _XOPEN_SOURCE, u_int et al Message-ID: <20160130172415.GB45228@stack.nl> References: <56ACECA2.10508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56ACECA2.10508@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 17:24:22 -0000 On Sat, Jan 30, 2016 at 06:02:26PM +0100, Matthias Andree wrote: > what is our stance on __STRICT_ANSI__ and thereabouts when compiling > code with -std=c99 or similar flags that includes, for instance, > (in turn including arpa/nameser.h) or ? > The issue is that under __STRICT_ANSI__, the local symbols aren't > exposed. So far, so good. Adding #define _XOPEN_SOURCE 700 doesn't > expose the typedefs for u_int, u_long and thereabouts, failing thus: > > In file included from killme.c:12: > > In file included from /usr/include/resolv.h:61: > > /usr/include/arpa/nameser.h:112:9: error: unknown type name 'u_char'; did you mean 'char'? > > typedef u_char ns_nname[NS_MAXNNAME]; > > ^ > This is a minimal program to show the issue: > /* save as killme.c, > and compile with cc -std=c99 -c killme.c to see me burn */ > #define _XOPEN_SOURCE 700 > #include > #include > #include > #include > #include > #include > int main(void) > { > puts("Hello, world"); > exit(0); > } > /*******************************************************/ > The root cause appears to be that under __STRICT_ANSI__ or under > _XOPEN_SOURCE, __BSD_VISIBLE remains undefined, thus the necessary > #if __BSD_VISIBLE > typedef unsigned char u_char; > typedef unsigned short u_short; > typedef unsigned int u_int; > typedef unsigned long u_long; > from sys/types.h do not apply. > One could argue A) that resolv.h isn't a POSIX header, but does POSIX > mandate us to burn when system extensions or contributions are used? POSIX does not specify extensions, so it permits breakage. We generally treat this very strictly, not exposing even extensions permitted by POSIX. > Or should B) we fix our headers of contributed sources such that we do > not use non-POSIX types? I certainly do not want additional types > polluting the namespace, but perhaps arpa/nameser.h, and many other > headers, can be fixed, to not use u_int. You could try that but you might find that you end up having to fix many things. It may be easier to modify your code to avoid use of the non-POSIX APIs or to restrict such use to files that do not request strict standards compliance. -- Jilles Tjoelker