Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly

[John Marino <gnugcc@marino.st>]

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