Bug 234205 - /usr/include/sys/file.h uses the u_int typedef which causes C compilation to sometimes fail
Summary: /usr/include/sys/file.h uses the u_int typedef which causes C compilation to ...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 12.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-20 13:14 UTC by Andras Farkas
Modified: 2018-12-27 18:52 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Farkas 2018-12-20 13:14:42 UTC
If you compile a program, and give -D_XOPEN_SOURCE=700 to the compiler, and the program has #include <sys/file.h> the compiler gives an error like this:
/usr/include/sys/file.h:226:2: error: unknown type name 'u_int'
        u_int   xf_flag;        /* flags (see fcntl.h) */
and then bails out.
Why is the u_int typedef used instead of 'unsigned int' itself?  It's unnecessary other than to save a couple keystrokes while typing.
Comment 1 Jilles Tjoelker freebsd_committer 2018-12-27 18:52:37 UTC
The current implementation of the feature test macros like _XOPEN_SOURCE that request strict standards compliance is that the application is assumed not to need any extensions. For the most part, defining such a macro hides things not belonging to the selected standard from header files listed in the standard. If a header file is used that is not in the standard, this is a bad idea: it either fails (as you see here) or exposes extensions to the standard.