__STRICT_ANSI__, __BSD_VISIBLE (cc -std=c99) vs. _XOPEN_SOURCE, u_int et al

Matthias Andree mandree at FreeBSD.org
Sat Jan 30 17:02:29 UTC 2016


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");

The root cause appears to be that under __STRICT_ANSI__ or under
_XOPEN_SOURCE, __BSD_VISIBLE remains undefined, thus the necessary

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?

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.

More information about the freebsd-standards mailing list