On 5/2/2014 01:03, Joseph S. Myers wrote: > The include of <sys/types.h> from <stddef.h> seems risky, given that > that's a POSIX header that typically defines various types ISO C does not > permit to be defined in <stddef.h> (ISO C does not have any general *_t > namespace reservation, unlike POSIX). > > Have you verified that if you include <stddef.h> with -std=c90 / -std=c99 > / -std=c11, the resulting definitions (compiler and preprocessor) are all > ones permitted by the relevant C standard version to be provided by > <stddef.h>?
You bring up some interesting points. I haven't specific tested anything like that, but DragonFly has been using this modification for years - since gcc 4.6 at least. It is even in the primary base compiler: http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/contrib/gcc-4.7/gcc/ginclude/stddef.h So given the track record (building itself, building base, building 21,000 software ports) over a couple of years I think any issues this could have caused would have been seen and identified by now. > > (I don't know what the FreeBSD <sys/_types.h> defines, but it at least > seems possible from the name that it is only defining things in the > implementation namespace, with the public <sys/types.h> being what then > includes <sys/_types.h> and does "typedef __foo_t foo_t;" or similar to > provide the public POSIX types that aren't in ISO C.) Here are the headers in question: http://grok.dragonflybsd.org/xref/freebsd/sys/sys/_types.h http://grok.dragonflybsd.org/xref/dragonfly/sys/sys/types.h Thanks, John
