Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <351B81C7.1F76@rug.ac.be>
Date: Fri, 27 Mar 1998 11:39:03 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: DJ Delorie <dj AT delorie DOT com>, eliz AT is DOT elta DOT co DOT il, salvador AT inti DOT gov DOT ar,
        blizzar AT hem1 DOT passagen DOT se, djgpp-workers AT delorie DOT com
Subject: Re: NULL redefined! :(
References: <199803252349 DOT SAA09833 AT delorie DOT com> <351A0E4B DOT 57F8 AT rug DOT ac DOT be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

I wrote:
> DJ's remark seems to imply otherwise (a modifyable lvalue, which makes a
> large difference), so, I have to check whether this holds a truth.

After some tests: it is definitely a ((non-modifiable)) rvalue.
 
> > 3. ANSI C explicitly states that NULL must be one of the following: 0,
> >    0L, or (void *)0.
> 
> I read in one of the latest C drafts (yes, a draft, hence no accepted
> standard) that (void*)0 is NOT an acceptable definition for NULL, but 0,
> 0L, 0LU and even, but not for us, 0LLU are.
> But as __null is NOT C, but C++ this does not matter.

I'll correct myself:
in C, (void*)0 is valid as definition of NULL, and so are 0 and 0L.
in C++, (void*)0 is not allowed as definition of NULL, but 0 and 0L (and
maybe __null) are.
The reason why it is not allowed is that, the following expression
should produce no errors:
  c_String *t = NULL;
When NULL is (void*)0, this will produce a warning (should be an error)
because (void*)0 is NOT the nil-pointer constant, and implicit assigning
from a different pointer type is never allowed in C++, at least not for
non-inherited classes.

C++ was supposed to be a superset of C, but it IS not.
Having such a small difference won't harm anyone.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/