Date: Thu, 20 Jul 2000 02:42:48 -0400 (EDT) Message-Id: <200007200642.CAA09333@indy.delorie.com> From: Eli Zaretskii To: mrs AT windriver DOT com CC: martin AT loewis DOT home DOT cs DOT tu-berlin DOT de, djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org, lauras AT softhome DOT net In-reply-to: <200007192138.OAA01286@kankakee.wrs.com> (message from Mike Stump on Wed, 19 Jul 2000 14:38:04 -0700 (PDT)) Subject: Re: GCC headers and DJGPP port References: <200007192138 DOT OAA01286 AT kankakee DOT wrs DOT com> 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 > From: Mike Stump > Date: Wed, 19 Jul 2000 14:38:04 -0700 (PDT) > > > Date: Wed, 19 Jul 2000 14:26:25 -0400 (EDT) > > From: Eli Zaretskii > > To: martin AT loewis DOT home DOT cs DOT tu-berlin DOT de > > > Seriously, though: the conclusion was that we didn't like the > > redefinition of NULL in C++ headers (see my other message for the > > problems this causes). But we couldn't understand why does the C++ > > compiler redefines NULL in its headers, so we couldn't find a > > solution that would satisfy us all and avoid breaking the C++ > > compiler at the same time. Perhaps you could help. > > Sure, change all definitions of NULL to more closely match gcc's > notion of null, and you're done. I'm not sure what GCC's notion of NULL are you talking about. We cannot use __null in C headers unconditionally, because it will cause unresolved externals in C programs, right? Use of __null conditioned on __cplusplus is questionable, since libc.a is not compiled with that definition of NULL. Am I missing something? > Sprinkle in #undef NULL if you get redefinition errors. We did use #undef to solve the immediate problem, but it looked like a brute-force and potentially dangerous (for C++ programs) solution. I wonder if there's a better one.