X-Authentication-Warning: acaxp6.physik.rwth-aachen.de: broeker owned process doing -bs Date: Thu, 9 Mar 2000 01:51:32 +0100 (MET) From: Hans-Bernhard Broeker To: djgpp-workers AT delorie DOT com Subject: Re: iso646.h and some questions In-Reply-To: <200003082010.PAA23972@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: dj-admin AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 8 Mar 2000, DJ Delorie wrote: > > > #include > > > #ifndef NULL > > > #define NULL _DJ_NULL > > > #endif > > > > I like this better. But isn't it cleaner to have all the #ifndef stuff > > inside sys/djnull.h, instead of exposing it to the public headers? > What's wrong with the solution we've been using? Nothing, maybe. I don't know enough C++ to understand why they broke C compatibility with their __null thingy, in the first place. If I assume there is a valid reason for that, we're breaking that aspect of C++, in our C current headers. My method would avoid that, by changing our NULL to __null automatically, when a C header is #include'd by the C++ compiler. > #include > __DJ_va_list > #undef __DJ_va_list > #define __DJ_va_list This works nicely for type definitions, not for macros. The equivalent trick wouldn't work for macros, as you cannot #define a macro that will #define another macro on evaluation, like you do with the typedef above. Putting the definition of _DJ_NULL into would be a misnomer, at the least. A new or a combination of both into something like looks better, to me. Especially since Martin Stroemberg dug out at least two other #defines that are set in more than one of the C99 headers (WCHAR_{MIN|MAX}). The reason for that header would be the same as that for djtypes: centralizing stuff for ease of maintenance. Just the way of using its macros has to be different. > As far as NULL itself is concerned, we've been through this before. > DJGPP's headers will replace g++'s NULL with a zero if they can. Yeah, but in letting C++ have the _null it so desparately wants, my solution should be a little more conservative. For the C side, we could now even move to '(void *)0', which C++ disallows, AFAIK. As it is, the value of NULL in a C++ program depends on wether a C or C++ standard header was last #include'd. In nasty cases, that may mean it's __null for one half of a source file, but 'magically' turns to '0' because someone #included a C header in the middle of nowhere. But this really all is speculation in thin air. What we need next are good answers to these two questions: 1) What do the C++ fathers need their __null for? 2) Is __null equivalent to a '0' or '(void *)0' if passed to or returned from a C function, i.e. would the C function ever recognized that the C++ program had '#define NULL __null' active? Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.