Sender:	bkorb AT sco DOT COM
Message-ID:	<397719F4.16F8A257@sco.com>
Date:	Thu, 20 Jul 2000 08:25:40 -0700
From:	Bruce Korb <bkorb AT sco DOT COM>
Organization:	Santa Cruz Operations
X-Mailer:	Mozilla 4.7 [en] (X11; I; SCO_SV 3.2 i386)
X-Accept-Language:	en
MIME-Version:	1.0
To:	DJ Delorie <dj AT delorie DOT com>
CC:	djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org
Subject:	Re: GCC headers and DJGPP port
References:	<200007180918 DOT FAA06988 AT indy DOT delorie DOT com> <200007181913 DOT VAA01170 AT loewis DOT home DOT cs DOT tu-berlin DOT de> <200007191826 DOT OAA08693 AT indy DOT delorie DOT com> <200007200729 DOT JAA01060 AT loewis DOT home DOT cs DOT tu-berlin DOT de> <200007201024 DOT GAA09536 AT indy DOT delorie DOT com> <200007201205.OA
Reply-To:	djgpp-workers AT delorie DOT com

DJ Delorie wrote:
> 
> > I don't know what your copy of stdio.h looks like, however, it
> > should certainly test whether NULL is defined before defining it.
> 
> It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
> NULL.  I have a philosophical problem with anyone saying "it should
> certainly test it" because it means that, at the whim of the gcc team,
> we'd need to add yet another test to our standard headers because yet
> another symbol was absconded by the gcc headers.  Where does it end?

The worst one *is* NULL.  The reason is that there are so bloody
many platforms out there that define it in all manner of random places.
I assume you know that.  GCC has to adapt itself to all these platforms.
fixincludes will no longer wrap #defines of NULL in the presence
of either "#if.*NULL" or a "#undef NULL".  It also always wraps the
typedefs for size_t, ptrdiff_t and wchar_t.  It does this on the 
assumption that they will be provided by GCC-supplied stddef.h.
The amusing thing about that is that stddef.h is not platform
specific, even though the SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE
defines are.  I'm thinking that fixincludes should do its thing
on the GCC-supplied stddef.h since fixincludes replaces these
typedefs with platform-specific changes (as of today :-).

> Of course, a working fixincludes might circumvent the technical
> problems.

I'm ready to help, but I don't have a DOS platform to play on.
(Don't really want one, either. ;)  The fork(2) and pipe(2) calls
can be gotten around with temporary files and system(3).

- Raw text -