Date: Sun, 8 Jul 2001 11:06:00 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: lauras AT softhome DOT net cc: djgpp-workers AT delorie DOT com Subject: Re: Comments on GCC 3.0 distribution In-Reply-To: <20010707175034.2473.qmail@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 7 Jul 2001 lauras AT softhome DOT net wrote: > > Thanks. But I'm still worried a bit: what about all those additional > > definitions we have in our headers which are private to DJGPP, or at > > least absent from the GCC headers? How will they be pulled in by GCC > > if it doesn't always do a include_next, and even when the header does > > include_next, I'm not convinced that really works in our case? > > 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. > As far as and 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). 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.