Date:	Tue, 13 Jun 2000 13:26:18 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	DJ Delorie <dj AT delorie DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Patch: sentinels for typedefs in headers
In-Reply-To:	<200006122111.RAA31720@envy.delorie.com>
Message-ID:	<Pine.SUN.3.91.1000613132539.16888Q-100000@is>
MIME-Version:	1.0
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

On Mon, 12 Jun 2000, DJ Delorie wrote:

> > __DJ_foo_t
> > #undef __DJ_foo_t
> > #define __DJ_foo_t
> 
> Note that I still think it's bogus that we have to bend to gcc's will,
> instead of them accepting posix-compatible headers.  But, I see no
> harm in the patch either, unless someday some *other* header uses
> those also to disable djgpp's specific declarations.

I agree (on both counts), but something bothers me with this change.
Effectively, it means that we use one definition of size_t and its ilk
when building GCC and another when building other programs and libc.a.

Are we absolutely sure that these definitions are *identical*?  If
not, we are shooting ourselves in the foot, because GCC might crash or
work incorrectly in some marginal cases, due to mismatch between its
definition of these types and the definitions we use to compile
libc.a.

Even if today these definitions are identical, they might diverge in
the future.  So perhaps it is a good idea to put some safeguards into
at least some of the affected headers that will yell bloody murder if
some day the definitions change in an incompatible way.  (Assuming
that the preprocessor is powerful enough to support such safeguards,
that is.)

> > I am not sure if wc204.txi needs updating, because this is internal
> > change.
> 
> It should, but only a minor note need be added.

Yes, I agree.  This is an internal change, but it might be exposed by
some, admittedly rare, uses of the library.

- Raw text -