Date:	Wed, 25 Mar 1998 18:49:50 -0500 (EST)
Message-Id:	<199803252349.SAA09833@delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	eliz AT is DOT elta DOT co DOT il
CC:	salvador AT inti DOT gov DOT ar, blizzar AT hem1 DOT passagen DOT se, djgpp-workers AT delorie DOT com
In-reply-to:	<Pine.SUN.3.91.980325172904.26F-100000@is> (message from Eli
	Zaretskii on Wed, 25 Mar 1998 17:31:52 +0300 (IDT))
Subject:	Re: NULL redefined! :(

> DJ, given these results, where exactly do we risk to break ANSI C 
> programs with the following in <stddef.h>:
> 
> 	#ifdef __cplusplus
> 	#define NULL __null
> 	#else
> 	#define NULL 0
> 	#endif

The problem is ANSI C++ programs - the C++ language is expected to be
a superset of ANSI C.  The C version of the macro works for C++ also,
so why add complexity where it isn't needed?  Why have a symbol that
has a different set of semantics depending on the language when you
don't need to?  My opinion is that this discussion has taken more
effort than the results warrant.  DJGPP shouldn't have to change to
adapt to third-party libraries when DJGPP is in compliance with the
published specifications.

void foo(int *x)
{
  if (x == NULL);
}

Comparison of different pointer types?  Once NULL has a type, there
are *less* things you can compare it against, not more.

Some other things:

1. WHY DO WE NEED THIS?  The "0" definition is perfectly fine, and has
   worked for what, twenty years or so?

2. "NULL = foo;" would suddenly start working.

3. ANSI C explicitly states that NULL must be one of the following: 0,
   0L, or (void *)0.

- Raw text -