misc/156637: sys/types.h can't be included when _XOPEN_SOURCE
streambag at streambag.se
Wed Apr 27 19:30:13 UTC 2011
The following reply was made to PR misc/156637; it has been noted by GNATS.
From: Robert Andersson <streambag at streambag.se>
To: Garrett Wollman <wollman at hergotha.csail.mit.edu>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: misc/156637: sys/types.h can't be included when _XOPEN_SOURCE
Date: Wed, 27 Apr 2011 21:22:55 +0200
On Mon, 25 Apr 2011 13:51:31 -0400 (EDT)
Garrett Wollman <wollman at hergotha.csail.mit.edu> wrote:
> >When including <sys/file.h> with _XOPEN_SOURCE defined to 500 or
> >higher, compila tion will fail with a message similar to this one
> >(using clang, gcc fails with a
> > similar message):
> Which edition of the standard specifies <sys/file.h>? It's not in my
> copy of Issue 6 (SUSv3) or Issue 7 (SUSv4).
> I'd say it's the application code that is in error. It should not be
> defining _XOPEN_SOURCE and then including (implementation private)
> header files which are not defined in the relevant standard.
> Do we seriously need to start writing our headers like:
> #include <sys/cdefs.h>
> #ifndef __BSD_VISIBLE
> #error "This is a non-standard header, but you have specified strict
> standard compliance." #endif
> ? This probably goes along with my fix to <sys/cdefs.h> which does:
> #ifdef __BSD_VISIBLE
> #error "Application defined preprocessor macro in the implementation
> namespace." #endif
I think you are right. I was confused about what _XOPEN_SOURCE meant.
By the way, I solved the problem by making sure that the
application only uses standardized headers. In this case it meant using
fcntl instead of flock. Hopefully, I will be able to push that upstream.
As far as I'm concerned, this PR can be closed. Thanks for your help
and sorry for the noise.
More information about the freebsd-bugs