Date: Sat, 30 Jan 2016 18:24:15 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Matthias Andree <mandree@FreeBSD.org> 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> In-Reply-To: <56ACECA2.10508@FreeBSD.org> References: <56ACECA2.10508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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,
> <resolv.h> (in turn including arpa/nameser.h) or <net/if_dl.h>?
> 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 <unistd.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <resolv.h>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160130172415.GB45228>