Mail Archives: djgpp-workers/2001/07/10/13:46:14
> > <limits.h> from GCC does include_next, and at least it worked a year ago.
>
> Yes, it does include_next, but only if some preprocessing symbol
> (whose name I forget and don't have the distro handy to look up) is
> defined. I only looked at limits.h for a few moments, but it seemed
> to me that this symbol will not be defined in our case, except if
> limits.h was already included at least once in the same source file.
> Perhaps I missed something.
Well, I don't have GCC sources right here to check it. Does our limits.h
have non-standard symbols, so that's the problem?
> > As far as <stdarg.h> and <stddef.h> are concerned, we don't have any
> > non-standard definitions there, do we?
>
> Our stddef.h includes sys/djtypes.h, which could mean it defines more
> types than stddef.h which comes with GCC (but I didn't actually
> compare them type by type, partially because the GCC version of that
> header is a terrible hodgepodge of ifdef's).
I don't understand. If stddef.h includes sys/djtypes.h but references
only few particular types found in GCC's stddef.h, then where's the problem?
> As for stdarg.h, it's probably okay if we know for sure their
> definitions of va_* macros don't contradict ours; perhaps we should
> have a short program to actually test them with all the supported data
> types.
I've already done that, when I made patches to use GCC builtins in our
headers some time ago.
Laurynas
- Raw text -