Bug 156637 - [headers] [patch] sys/types.h can't be included when _XOPEN_SOURCE is defined
Summary: [headers] [patch] sys/types.h can't be included when _XOPEN_SOURCE is defined
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-25 09:20 UTC by Robert Andersson
Modified: 2018-03-28 03:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Andersson 2011-04-25 09:20:18 UTC
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):

In file included from main.c:3:
/usr/include/sys/file.h:161:2: error: unknown type name 'u_int'
        u_int   xf_flag;        /* flags (see fcntl.h) */

u_int is defined in types.h, but it is wrapped in a #if __BSD_VISIBLE.

__BSD_VISIBLE is defined in cdefs.h only if _POSIX_C_SOURCE is not defined (whic
h it is if _XOPEN_SOURCE is defined).

I found the following (short) thread about this problem from 2009:
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg69469.html

Fix: 

I'm not sure what the correct solution is. Any one of the following would solve the problem:
* sys/file.h should not use u_int
* The relevant parts of sys/file.h should be wrapped in #if __BSD_VISIBLE
* The definition of u_int should not be wrapped in #if __BSD_VISIBLE
* _XOPEN_SOURCE >= 500 should not imply _POSIX_C_SOURCE
* _POSIX_C_SOURCE should not stop __BSD_VISIBLE from being defined.
How-To-Repeat: Try to compile the following code:

#define _XOPEN_SOURCE 500
#include <sys/file.h>

int main(int argc, char *argv[]) {
    return 0;
}
Comment 1 Bruce Evans freebsd_committer freebsd_triage 2011-04-25 10:10:00 UTC
I've used the following fix (the first of the above) for 10 years or
so (it got lost in fixes for mounds of style bugs in <sys/file.h>).
I didn't notice it in connection with _XOPEN_SOURCE, but by general
principles.

% Index: file.h
% ===================================================================
% RCS file: /home/ncvs/src/sys/sys/file.h,v
% retrieving revision 1.65
% diff -u -2 -r1.65 file.h
% --- file.h	19 Jun 2004 11:38:00 -0000	1.65
% +++ file.h	20 Jun 2004 02:11:04 -0000
% @@ -151,5 +142,5 @@
%  	void	*xf_data;	/* file descriptor specific data */
%  	void	*xf_vnode;	/* vnode pointer */
% -	u_int	xf_flag;	/* flags (see fcntl.h) */
% +	unsigned xf_flag;	/* flags (see fcntl.h) */
%  };
%

Bruce
Comment 2 Robert Andersson 2011-04-25 16:44:31 UTC
Hi,

Thanks for responding! Your patch definitely solves the problem. I
found this when trying to port an application to FreeBSD. I guess I can
work around the problem by patching the code using file.h
to define __BSD_VISIBLE, but it would be great
if this fix could be committed so that the workaround can be removed
eventually.

Cheers,
Robert
Comment 3 Garrett Wollman 2011-04-25 18:51:31 UTC
>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

-GAWollman
Comment 4 Robert Andersson 2011-04-27 20:22:55 UTC
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.

/ Robert
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:22 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2018-03-28 03:06:07 UTC
Closing per comment 4 (application issue)