This is the mail archive of the gcc@gcc.gnu.org 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]

Re: GCC headers and DJGPP port


Zack Weinberg wrote:
> As I said, __SIZE_TYPE__ et al are magic defines, built into cpp.  You
> must have missed this chunk of cppinit.c:
> 
> static const struct builtin builtin_array[] =
> {
>   /* ... */
> #ifndef NO_BUILTIN_SIZE_TYPE
>   C("__SIZE_TYPE__",            SIZE_TYPE),

Ah, that is very different.  Never mind  :-).
It was not what I was expecting, so it was not what I saw.

> I do not know why stddef.h has default definitions of these macros;
> perhaps in case a non-GCC compiler ever used our stddef.h.

Now *that* is curious.  Some of the headers also force an error
if the compiler is not GCC...

> The vast majority of the complexity of stddef.h has to do with how it
> interacts with system-provided headers.  Not on the actual definition
> of size_t, etc. but on the interlock mechanism which prevents
> duplicate typedefs.  And I don't think fixincludes is prepared to help
> with that.  It would need a huge table recording the appropriate
> interlock to use for each platform.

No.  Actually, fixincludes has always "fixed" the headers
that typedef these by wrapping them as I described.  What would
happen if someone #include-d stddef.h before another system
header that typedefed the same thing?  Nothing bad only because
fixincludes was there first and wrapped the duplicate typedef.
Since this has already been done, and since you can rely on it,
it seems that the complexity is unnecessary, yes?

> I might also add that some modern C libraries, such as glibc, know
> exactly which headers are provided by gcc and do not have their own
> copies.
??

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