Date: Tue, 13 Jun 2000 13:26:18 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: DJ Delorie 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: 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 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.