delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/08/20:10:25

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 <broeker AT physik DOT rwth-aachen DOT de>
To: djgpp-workers AT delorie DOT com
Subject: Re: iso646.h and some questions
In-Reply-To: <200003082010.PAA23972@envy.delorie.com>
Message-ID: <Pine.OSF.4.10.10003090129001.29299-100000@acaxp6.physik.rwth-aachen.de>
MIME-Version: 1.0
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

On Wed, 8 Mar 2000, DJ Delorie wrote:

> > > 	#include <sys/djnull.h>
> > > 	#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 <sys/djtypes.h>
> 	__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 <sys/djtypes.h> would be a
misnomer, at the least. A new <sys/djdefines.h> or a combination of both
into something like <sys/djconfig.h> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019