This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:

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:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]