Re: C++ definition of NULL

Re: C++ definition of NULL

[Jason Merrill]

>>>>> Chad Gatesman <chadg@redrose.net> writes:

 > I am currently porting a very large library that depends on the passing
 > of NULL into parameters declared as long int.

 > egcs appears to define NULL as __null which is a builtin symbol that
 > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
 > a long int parameter without casting it.

Why would you want to?  Conceptually, NULL is a pointer value.

Jason

Re: C++ definition of NULL

[Chad Gatesman]

Jason Merrill wrote:

>  > I am currently porting a very large library that depends on the passing
>  > of NULL into parameters declared as long int.
>
>  > egcs appears to define NULL as __null which is a builtin symbol that
>  > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
>  > a long int parameter without casting it.
>
> Why would you want to?  Conceptually, NULL is a pointer value.

I see what you are saying, but unfortunately, this is not my code.  I am
mearly porting it.  And, technically, it should work since the standard says
NULL should be a 0 or 0L

Chad Gatesman

Re: C++ definition of NULL

[Gabriel Dos Reis]

>>>>> Chad Gatesman <chadg@redrose.net> wrote:

> Jason Merrill wrote:
>> > I am currently porting a very large library that depends on the passing
>> > of NULL into parameters declared as long int.
>> 
>> > egcs appears to define NULL as __null which is a builtin symbol that
>> > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
>> > a long int parameter without casting it.
>> 
>> Why would you want to?  Conceptually, NULL is a pointer value.

> I see what you are saying, but unfortunately, this is not my code.  I am
> mearly porting it.  And, technically, it should work since the standard says
> NULL should be a 0 or 0L
       ^^^^^^^^

No. The C++ Standard does not say anything like that. The exact
wording is:

18.1/4
---
  The macro NULL is an implementation-defined C++ null pointer
  constant in this Internnational Standard (4.10).
---

Footnote says:

---
  Possible definitions include 0 and OL, but not (void*)0.
---

Please notice that integer type is not limited to int or long int. It
includes bool, char, short, ...

But I agree with you that the compiler should have selected
func(long) is NULL is of integer type.

-- Gaby

Re: C++ definition of NULL

[Chad Gatesman]

Gabriel Dos Reis wrote:

> > I see what you are saying, but unfortunately, this is not my code.  I am
> > mearly porting it.  And, technically, it should work since the standard says
> > NULL should be a 0 or 0L
>        ^^^^^^^^
>
> No. The C++ Standard does not say anything like that. The exact
> wording is:
>
> 18.1/4
> ---
>   The macro NULL is an implementation-defined C++ null pointer
>   constant in this Internnational Standard (4.10).
> ---
>
> Footnote says:
>
> ---
>   Possible definitions include 0 and OL, but not (void*)0.
> ---
>
> Please notice that integer type is not limited to int or long int. It
> includes bool, char, short, ...
>
> But I agree with you that the compiler should have selected
> func(long) is NULL is of integer type.

Yes, possibly selecting it and issuing a warning.  If you look at the behavior
with one function, it will select it and issue a warning, but when it has to deal
with overloaded functions it fails completely.  Bug?

Chad Gatesman

Re: C++ definition of NULL

[Martin v. Loewis]

> Yes, possibly selecting it and issuing a warning.  If you look at
> the behavior with one function, it will select it and issue a
> warning, but when it has to deal with overloaded functions it fails
> completely.  Bug?

Yes, it looks like this is a bug in egcs 1.1.1. I haven't checked
whether the bug is still present in 1.1.2, however, it appears it is
fixed in the current development snapshots (egcs-2.93.10).

From that, it appears you have a number of options:

a) Replace all occurences of NULL with 0. This is IMHO the Right Thing
   (tm), because the NULL symbol is an ugly hack, and just there for
   backwards compatibility.

b) Use a more current egcs release. You've indicated that you need
   production quality, so this is probably not an option.

c) Change your installation of egcs to define NULL in whatever way you
   think is appropriate.

Regards,
Martin

Re: C++ definition of NULL

[Per Bothner]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
> a) Replace all occurences of NULL with 0. This is IMHO the Right Thing
>    (tm), because the NULL symbol is an ugly hack, and just there for
>    backwards compatibility.

You've got it backwards.  It is defining integer literal 0 as the
null pointer which is the ugly hack, but we're stuck with it
because of backwards compatibility.

On the other hand, using NULL as the null pointer is sanctioned
by common sense, tradition, helps code readability, and (using
some name or other) is what every other high-level language
providing pointers does.

The C++ committee blew this one.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: C++ definition of NULL

[Martin v. Loewis]

> On the other hand, using NULL as the null pointer is sanctioned
> by common sense, tradition, helps code readability, and (using
> some name or other) is what every other high-level language
> providing pointers does.
> 
> The C++ committee blew this one.

It seems we disagree. If the committee wanted to introduce a reserved
name for the null pointer constant, NULL definitely would have been a
bad choice, because people have all kinds of views what NULL is
(including (void*)0 and (char*)0). Also, people just *know* that NULL
is a macro. The way NULL is defined really reflects all this confusing
tradition, and is a bad start for defining a clean concept of 'null
pointer'.

I'm not sure how much readability is lost in a language if the null
pointer constant is removed. I found that people typically understand
very quickly that the right way to express a null pointer is to write
'0'. This is especially true since this constant needs all kinds of
funny polymorphic properties. Explaining that a conversion is going on
to the specific type required is much easier when you see that you
start off with a number literal.

Regards,
Martin

Re: C++ definition of NULL

[Tomislav Goles]

> > 
> > The C++ committee blew this one.
> 
> It seems we disagree. If the committee wanted to introduce a reserved
> name for the null pointer constant, NULL definitely would have been a
> bad choice, because people have all kinds of views what NULL is
> (including (void*)0 and (char*)0). Also, people just *know* that NULL
> is a macro. The way NULL is defined really reflects all this confusing
> tradition, and is a bad start for defining a clean concept of 'null
> pointer'.
> 
> I'm not sure how much readability is lost in a language if the null
> pointer constant is removed. I found that people typically understand
> very quickly that the right way to express a null pointer is to write
> '0'. This is especially true since this constant needs all kinds of
> funny polymorphic properties. Explaining that a conversion is going on
> to the specific type required is much easier when you see that you
> start off with a number literal.
> 

I happen to agree with Martin. But even if I did not I still think NULL
should be removed because the committee (rightly or wrongly) decided so.
Any complaints about this decision I think should be directed to
the committee. In the mean time, egcs would be better off being compliant
and doing away with NULL unless the committee decides to overrule itself.

Tomislav Goles

Re: C++ definition of NULL

[Per Bothner]

> I happen to agree with Martin. But even if I did not I still think NULL
> should be removed because the committee (rightly or wrongly) decided so.

Er, removing NULL is not an option, because it is required by the standard.
Furthermore, I have not proposed that NULL not be a macro.

What I am unhappy about is the C++ committee disallowing (void*)0
as the definition of NULL.  This prevents the compiler from diagnosing
certain errors (I have no opinion on how common or damaging these
errors are), unless the compilers uses some special magic tricks.
G++ does use suchs tricks (I don't know the details), but using
(void*)0 would have been better, I think.

I am also unhappy about style guides that discourage use of NULL.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: C++ definition of NULL

[Martin v. Loewis]

> In the mean time, egcs would be better off being compliant and doing
> away with NULL unless the committee decides to overrule itself.

Most certainly. It seems that g++ has chosen a strict interpretation
of the standard, by using some magic symbol __null that happens to be
a null pointer constant. As Jason points out, even 1.1.1 behaves
compliant when called with -ansi (which means strict compliance).

Regards,
Martin

Re: C++ definition of NULL

[David Edelsohn]

	Again, this is a bug in egcs-1.1 which is fixed in the current
development snapshots.  As I said in the original reply, the fix appears
to be too involved to include in egcs-1.1.2 (I already requested that it
be added and the discussion resulted that it is too dangerous).

	egcs-1.1.1 -ansi option will make NULL an integral mode but it
also enables other features, unfortunately.

David

Re: C++ definition of NULL

[Marc Espie]

In article < 199903031616.IAA18283@cygnus.com > you write:
>I am also unhappy about style guides that discourage use of NULL.


I thoroughly discourage use of NULL in code I write, and in any style
guide I would write.

Why ?

Well, I guess this discussion amply proves that NULL is not worth the 
trouble.  It's only half-portable, compilers hardly agree on what to do
with it, and you have to compile with -ansi to get standard compliance
from egcs.

Yes, I know that what's -ansi does, but this looks a bit like a straitjacket:
-ansi is a choice on a lot of issues, I don't like having this choice taken
away just for using NULL.

Besides that, NULL seems to imply it is magical. It does not hold its promises:
it it just a decorated integer constant, at least on most compilers.
Whereas 0 does not hold any getcha. You know you've got to cast it if you
use it in an ambiguous context.  Try showing weird code that uses NULL to
beginners... good luck getting them to understand why it's not portable.

The committee blew it: there should be another constant, a NIL or something,
based on any sane pointer definition, like what Meyer writes at the end
of Effective C++.   NULL needs to stay the way it is for compatibility with
legacy code.

But avoiding NULL is just plain common sense. :)

Re: C++ definition of NULL

[Jean-Pierre Radley]

Marc Espie averred (on Thu, Mar 04, 1999 at 03:32:17AM +0100):
| 
| The committee blew it: there should be another constant, a NIL or something,
| based on any sane pointer definition, like what Meyer writes at the end
| of Effective C++.   NULL needs to stay the way it is for compatibility with
| legacy code.

I use a NIL definition, with due credit, in some of my header files:

	/*  I prefer this NIL macro to present a NIL pointer than most other
	    variations that I have seen (eg, NULL, 0, or (cast) 0.
	    Comme ci, comme ca. - larry gensch
	*/
	#ifndef NIL
	# define    NIL(type)   (type *) 0
	#endif

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: C++ definition of NULL

[Marc Espie]

In article < 199903031616.IAA18283@cygnus.com > you write:
>I am also unhappy about style guides that discourage use of NULL.


I thoroughly discourage use of NULL in code I write, and in any style
guide I would write.

Why ?

Well, I guess this discussion amply proves that NULL is not worth the 
trouble.  It's only half-portable, compilers hardly agree on what to do
with it, and you have to compile with -ansi to get standard compliance
from egcs.

Yes, I know that what's -ansi does, but this looks a bit like a straitjacket:
-ansi is a choice on a lot of issues, I don't like having this choice taken
away just for using NULL.

Besides that, NULL seems to imply it is magical. It does not hold its promises:
it it just a decorated integer constant, at least on most compilers.
Whereas 0 does not hold any getcha. You know you've got to cast it if you
use it in an ambiguous context.  Try showing weird code that uses NULL to
beginners... good luck getting them to understand why it's not portable.

The committee blew it: there should be another constant, a NIL or something,
based on any sane pointer definition, like what Meyer writes at the end
of Effective C++.   NULL needs to stay the way it is for compatibility with
legacy code.

But avoiding NULL is just plain common sense. :)

Re: C++ definition of NULL

[Martin v. Loewis]

> Yes, possibly selecting it and issuing a warning.  If you look at
> the behavior with one function, it will select it and issue a
> warning, but when it has to deal with overloaded functions it fails
> completely.  Bug?

Yes, it looks like this is a bug in egcs 1.1.1. I haven't checked
whether the bug is still present in 1.1.2, however, it appears it is
fixed in the current development snapshots (egcs-2.93.10).

From that, it appears you have a number of options:

a) Replace all occurences of NULL with 0. This is IMHO the Right Thing
   (tm), because the NULL symbol is an ugly hack, and just there for
   backwards compatibility.

b) Use a more current egcs release. You've indicated that you need
   production quality, so this is probably not an option.

c) Change your installation of egcs to define NULL in whatever way you
   think is appropriate.

Regards,
Martin

Re: C++ definition of NULL

[Tomislav Goles]

> > 
> > The C++ committee blew this one.
> 
> It seems we disagree. If the committee wanted to introduce a reserved
> name for the null pointer constant, NULL definitely would have been a
> bad choice, because people have all kinds of views what NULL is
> (including (void*)0 and (char*)0). Also, people just *know* that NULL
> is a macro. The way NULL is defined really reflects all this confusing
> tradition, and is a bad start for defining a clean concept of 'null
> pointer'.
> 
> I'm not sure how much readability is lost in a language if the null
> pointer constant is removed. I found that people typically understand
> very quickly that the right way to express a null pointer is to write
> '0'. This is especially true since this constant needs all kinds of
> funny polymorphic properties. Explaining that a conversion is going on
> to the specific type required is much easier when you see that you
> start off with a number literal.
> 

I happen to agree with Martin. But even if I did not I still think NULL
should be removed because the committee (rightly or wrongly) decided so.
Any complaints about this decision I think should be directed to
the committee. In the mean time, egcs would be better off being compliant
and doing away with NULL unless the committee decides to overrule itself.

Tomislav Goles

Re: C++ definition of NULL

[Gabriel Dos Reis]

>>>>> Chad Gatesman <chadg@redrose.net> wrote:

> Jason Merrill wrote:
>> > I am currently porting a very large library that depends on the passing
>> > of NULL into parameters declared as long int.
>> 
>> > egcs appears to define NULL as __null which is a builtin symbol that
>> > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
>> > a long int parameter without casting it.
>> 
>> Why would you want to?  Conceptually, NULL is a pointer value.

> I see what you are saying, but unfortunately, this is not my code.  I am
> mearly porting it.  And, technically, it should work since the standard says
> NULL should be a 0 or 0L
       ^^^^^^^^

No. The C++ Standard does not say anything like that. The exact
wording is:

18.1/4
---
  The macro NULL is an implementation-defined C++ null pointer
  constant in this Internnational Standard (4.10).
---

Footnote says:

---
  Possible definitions include 0 and OL, but not (void*)0.
---

Please notice that integer type is not limited to int or long int. It
includes bool, char, short, ...

But I agree with you that the compiler should have selected
func(long) is NULL is of integer type.

-- Gaby

Re: C++ definition of NULL

[David Edelsohn]

	Again, this is a bug in egcs-1.1 which is fixed in the current
development snapshots.  As I said in the original reply, the fix appears
to be too involved to include in egcs-1.1.2 (I already requested that it
be added and the discussion resulted that it is too dangerous).

	egcs-1.1.1 -ansi option will make NULL an integral mode but it
also enables other features, unfortunately.

David

Re: C++ definition of NULL

[Chad Gatesman]

Gabriel Dos Reis wrote:

> > I see what you are saying, but unfortunately, this is not my code.  I am
> > mearly porting it.  And, technically, it should work since the standard says
> > NULL should be a 0 or 0L
>        ^^^^^^^^
>
> No. The C++ Standard does not say anything like that. The exact
> wording is:
>
> 18.1/4
> ---
>   The macro NULL is an implementation-defined C++ null pointer
>   constant in this Internnational Standard (4.10).
> ---
>
> Footnote says:
>
> ---
>   Possible definitions include 0 and OL, but not (void*)0.
> ---
>
> Please notice that integer type is not limited to int or long int. It
> includes bool, char, short, ...
>
> But I agree with you that the compiler should have selected
> func(long) is NULL is of integer type.

Yes, possibly selecting it and issuing a warning.  If you look at the behavior
with one function, it will select it and issue a warning, but when it has to deal
with overloaded functions it fails completely.  Bug?

Chad Gatesman

Re: C++ definition of NULL

[Martin v. Loewis]

> In the mean time, egcs would be better off being compliant and doing
> away with NULL unless the committee decides to overrule itself.

Most certainly. It seems that g++ has chosen a strict interpretation
of the standard, by using some magic symbol __null that happens to be
a null pointer constant. As Jason points out, even 1.1.1 behaves
compliant when called with -ansi (which means strict compliance).

Regards,
Martin

Re: C++ definition of NULL

[Jason Merrill]

>>>>> Chad Gatesman <chadg@redrose.net> writes:

 > I am currently porting a very large library that depends on the passing
 > of NULL into parameters declared as long int.

 > egcs appears to define NULL as __null which is a builtin symbol that
 > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
 > a long int parameter without casting it.

Why would you want to?  Conceptually, NULL is a pointer value.

Jason

Re: C++ definition of NULL

[Chad Gatesman]

Jason Merrill wrote:

>  > I am currently porting a very large library that depends on the passing
>  > of NULL into parameters declared as long int.
>
>  > egcs appears to define NULL as __null which is a builtin symbol that
>  > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
>  > a long int parameter without casting it.
>
> Why would you want to?  Conceptually, NULL is a pointer value.

I see what you are saying, but unfortunately, this is not my code.  I am
mearly porting it.  And, technically, it should work since the standard says
NULL should be a 0 or 0L

Chad Gatesman

Re: C++ definition of NULL

[Per Bothner]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
> a) Replace all occurences of NULL with 0. This is IMHO the Right Thing
>    (tm), because the NULL symbol is an ugly hack, and just there for
>    backwards compatibility.

You've got it backwards.  It is defining integer literal 0 as the
null pointer which is the ugly hack, but we're stuck with it
because of backwards compatibility.

On the other hand, using NULL as the null pointer is sanctioned
by common sense, tradition, helps code readability, and (using
some name or other) is what every other high-level language
providing pointers does.

The C++ committee blew this one.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: C++ definition of NULL

[Per Bothner]

> I happen to agree with Martin. But even if I did not I still think NULL
> should be removed because the committee (rightly or wrongly) decided so.

Er, removing NULL is not an option, because it is required by the standard.
Furthermore, I have not proposed that NULL not be a macro.

What I am unhappy about is the C++ committee disallowing (void*)0
as the definition of NULL.  This prevents the compiler from diagnosing
certain errors (I have no opinion on how common or damaging these
errors are), unless the compilers uses some special magic tricks.
G++ does use suchs tricks (I don't know the details), but using
(void*)0 would have been better, I think.

I am also unhappy about style guides that discourage use of NULL.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: C++ definition of NULL

[Jean-Pierre Radley]

Marc Espie averred (on Thu, Mar 04, 1999 at 03:32:17AM +0100):
| 
| The committee blew it: there should be another constant, a NIL or something,
| based on any sane pointer definition, like what Meyer writes at the end
| of Effective C++.   NULL needs to stay the way it is for compatibility with
| legacy code.

I use a NIL definition, with due credit, in some of my header files:

	/*  I prefer this NIL macro to present a NIL pointer than most other
	    variations that I have seen (eg, NULL, 0, or (cast) 0.
	    Comme ci, comme ca. - larry gensch
	*/
	#ifndef NIL
	# define    NIL(type)   (type *) 0
	#endif

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: C++ definition of NULL

[Martin v. Loewis]

> On the other hand, using NULL as the null pointer is sanctioned
> by common sense, tradition, helps code readability, and (using
> some name or other) is what every other high-level language
> providing pointers does.
> 
> The C++ committee blew this one.

It seems we disagree. If the committee wanted to introduce a reserved
name for the null pointer constant, NULL definitely would have been a
bad choice, because people have all kinds of views what NULL is
(including (void*)0 and (char*)0). Also, people just *know* that NULL
is a macro. The way NULL is defined really reflects all this confusing
tradition, and is a bad start for defining a clean concept of 'null
pointer'.

I'm not sure how much readability is lost in a language if the null
pointer constant is removed. I found that people typically understand
very quickly that the right way to express a null pointer is to write
'0'. This is especially true since this constant needs all kinds of
funny polymorphic properties. Explaining that a conversion is going on
to the specific type required is much easier when you see that you
start off with a number literal.

Regards,
Martin

Re: C++ definition of NULL

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Mar  3, 1999, Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> wrote:

> NULL is *not* a pointer. NULL is _convertible_ to pointer type. More
> explicitly, the C++ Standard says:

> 4.10/1
> ---
>   A null pointer constant is na integral expression (5.19) rvalue of
>   integer type that evaluates to zero.
> ---

> So NULL is of integer type. Exactly wich one is implementation-defined.

Actually, it needs not be an integer type; the definition

enum __NULL_type { __null = 0 };
#define NULL __null

is a valid one, because integral expressions may involve enumerators.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: C++ definition of NULL

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Mar  3, 1999, "Doug Semler" <doug@seaspace.com> wrote:

> So the way I read the standard, the type of a null pointer constant is
> a pointer type of pointer to destination's cv-qualified type.

> eg:
> int *a = NULL ;   // NULL has type int *
> int a = NULL;    // Error: cannot implicitly convert pointer type to int

> Right?????

Nope.  Since NULL is an integral expression, it can be converted to
int, so there's no error above.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: C++ definition of NULL

[Chad Gatesman]

Jason Merrill wrote:

> Chad, please try compiling with -ansi.  In 1.1, when -ansi is on, __null is
> of integral type.

This breaks all kinds of code, and removes internal defines that the code
depends on to determine the platform I am on.


Martin Knoblauch wrote:

>  Hmm. Are you now assuming that sizeof(long) == sizeof(void *)?
> What if the IA64 Unixes come out as LL-P-64, leaving "long" at
> 32 bit to make porting M$ legacy software easier? While it is
> a hassle in the short term, explicitely casting will make things
> easier in the long run.

The code is assuming this, unfortunately.  But it has been common practice (and
I believe it will remain) that long is the size of a pointer.  The code is
already ported to 8 platforms (including 64-bit), and this hasn't been an
issue.


Thomas Kunert wrote:

> Since NULL is a constant casting it is rather dumb. Your usage of that
> constant is not intended by the standard and hence misguiding. Instead
> of casting I'd replace any `NULL' with `0'. This is easily done using
> something like sed. Then your code will compile and becomes more
> readable.

As I have said before, this is existing code (not mine), and even though it is
not so "proper" (which I agree), it should still work if NULL is defined as the
standard suggests.


"Martin v. Loewis" wrote:

> Yes, it looks like this is a bug in egcs 1.1.1. I haven't checked
> whether the bug is still present in 1.1.2, however, it appears it is
> fixed in the current development snapshots (egcs-2.93.10).

This has been pointed out to me, and I am glat to hear this.  Do we have any
idea when it would make it into a regular release?  The following version
(1.1.3 or 1.2 (which ever comes first))?

> From that, it appears you have a number of options:
>
> a) Replace all occurences of NULL with 0. This is IMHO the Right Thing
>    (tm), because the NULL symbol is an ugly hack, and just there for
>    backwards compatibility.
>
> b) Use a more current egcs release. You've indicated that you need
>    production quality, so this is probably not an option.
>
> c) Change your installation of egcs to define NULL in whatever way you
>    think is appropriate.

Re: C++ definition of NULL

[Jason Merrill]

Chad, please try compiling with -ansi.  In 1.1, when -ansi is on, __null is
of integral type.

Jason

Re: C++ definition of NULL

[Jason Merrill]

>>>>> Doug Semler <doug@seaspace.com> writes:

 > A Null pointer constant is a constant rvalue integral *expression*  which
 > evaluates to 0.
 >  The Null pointer value (the value of the expression) can be converted to a
 > cv-qualified type.
 >  The conversion from the expression is one
 >  step. So any constant integral rvalue of 0 can be a null pointer constant.

 > So the way I read the standard, the type of a null pointer constant is
 > a pointer type of pointer to destination's cv-qualified type.

No.  How would you write that?  The type of a null pointer constant is the
type of the integral expression.

Jason

C++ definition of NULL

[Chad Gatesman]

I am currently porting a very large library that depends on the passing
of NULL into parameters declared as long int.

egcs appears to define NULL as __null which is a builtin symbol that
treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
a long int parameter without casting it.

e.g.

#include <stdlib.h>

void func(long i)
{
}

void func(int a, int b)
{
}

void main()
{
    func(NULL);
}

> g++ -Wall -c t.cxx
t.cxx:12: warning: return type for `main' changed to `int'
t.cxx: In function `int main(...)':
t.cxx:13: no matching function for call to `func (NULL)'
t.cxx:4: candidates are: func(long int)
t.cxx:8:                 func(int, int)


If this is the case, how can I disable this behavior and use NULL as a
typical 0.  I don't want to have to put a -DNULL=0 in my compile lines,
and I can't  assume that just taking care of it with a redefine in one
of my headers would take care of it, because someone using the library
could end up getting the NULL redefined back to __null.  It would be
nice if the definition in stddef.h was as follows:

#ifndef NULL
#define NULL __null
#endif

Instead of:

#undef
#define NULL __null

Is there a reason it is done this way?  Since it is this why, it
prevents me from redefining it after it is defined the first time and
assuming it will remain that way.

Another thing.  Should this behavior really exist?  The standard states
that NULL should be defined as 0 or 0L.

Suggestions on a good workaround would be nice, but I think this is not
the way NULL should be implemented and it should be reconsidered
defining it as 0.

Thanks,
Chad Gatesman

Re: C++ definition of NULL

[Marc Girod]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

Per> On the other hand, using NULL as the null pointer is sanctioned
Per> by common sense, tradition, helps code readability, and (using
Per> some name or other) is what every other high-level language
Per> providing pointers does.

Well, I am lacking common sense and saying "no thanks" to this kind of
help in readability with Martin.
And probably standing on my head while looking at the heights.

I agree with your mention of tradition though.

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: C++ definition of NULL

[Chad Gatesman]

David Edelsohn wrote:

>         You do not mention which release of EGCS you are using, but I
> presume that you are refering to egcs-1.1.X and not the development
> snapshots.  There is a bug related to this in egcs-1.1 which is fixed in
> the development sources.  Unfortunately it looks like the fix is too
> involved to include in an egcs-1.1 update.

Excuse me.  That was pretty thoughtless of me.  I'm using egcs-1.1.1.  Do
you know what all the fix intailed or how I can easily find out?  Would it
be in egcs-1.1.2?  I really don't want to move our production compiler to a
snapshot ;)

Thanx,
Chad Gatesman

Re: C++ definition of NULL

[David Edelsohn]

	You do not mention which release of EGCS you are using, but I
presume that you are refering to egcs-1.1.X and not the development
snapshots.  There is a bug related to this in egcs-1.1 which is fixed in
the development sources.  Unfortunately it looks like the fix is too
involved to include in an egcs-1.1 update.

David

Re: C++ definition of NULL

[Alan Lehotsky]

This has long since gone off topic.  Move it to comp.lang.c++, please!

Re: C++ definition of NULL

[Gabriel Dos Reis]

>>>>> Doug Semler <doug@seaspace.com> wrote:

[...]


> Correct ,me if I'm wrong, but the standard says NULL is implementation
> defined, with
> (footnoted) possible values being 0 or 0L but not (void *)0

right.

> You should cast, you shouldn't implicitely convert pointers to integers any
> more.... :)


NULL is *not* a pointer. NULL is _convertible_ to pointer type. More
explicitly, the C++ Standard says:

4.10/1
---
  A null pointer constant is na integral expression (5.19) rvalue of
  integer type that evaluates to zero.
---

So NULL is of integer type. Exactly wich one is implementation-defined.

-- Gaby

Re: C++ definition of NULL

[Chad Gatesman]

Doug Semler wrote:

> Correct ,me if I'm wrong, but the standard says NULL is implementation
> defined, with
> (footnoted) possible values being 0 or 0L but not (void *)0

This is correct.

> You should cast, you shouldn't implicitely convert pointers to integers any
> more.... :)

The standard does not say this.  If NULL is defined as they suggested, one
would be able to be implicitly casted to a long.  I would hate to have to go
thru 1 million+ lines of code just to cast all occurances of NULL and force
users of the library to do the same.

Chad Gatesman

Re: C++ definition of NULL

[Doug Semler]

----- Original Message -----
From: Chad Gatesman <chadg@redrose.net>
To: Jason Merrill <jason@cygnus.com>
Cc: <egcs@cygnus.com>
Sent: Tuesday, March 02, 1999 9:10 PM
Subject: Re: C++ definition of NULL


>Jason Merrill wrote:
>
>>  > I am currently porting a very large library that depends on the
passing
>>  > of NULL into parameters declared as long int.
>>
>>  > egcs appears to define NULL as __null which is a builtin symbol that
>>  > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL
to
>>  > a long int parameter without casting it.
>>
>> Why would you want to?  Conceptually, NULL is a pointer value.
>
>I see what you are saying, but unfortunately, this is not my code.  I am
>mearly porting it.  And, technically, it should work since the standard
says
>NULL should be a 0 or 0L


Correct ,me if I'm wrong, but the standard says NULL is implementation
defined, with
(footnoted) possible values being 0 or 0L but not (void *)0

You should cast, you shouldn't implicitely convert pointers to integers any
more.... :)
---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: C++ definition of NULL

[Martin Knoblauch]

---Chad Gatesman <chadg@redrose.net> wrote:
>
> Doug Semler wrote:
> 
> > You should cast, you shouldn't implicitely convert pointers to
integers any
> > more.... :)
> 
> The standard does not say this.  If NULL is defined as they
suggested, one
> would be able to be implicitly casted to a long.  I would hate to
have to go
> thru 1 million+ lines of code just to cast all occurances of NULL
and force
> users of the library to do the same.
> 

 Hmm. Are you now assuming that sizeof(long) == sizeof(void *)?
What if the IA64 Unixes come out as LL-P-64, leaving "long" at
32 bit to make porting M$ legacy software easier? While it is
a hassle in the short term, explicitely casting will make things
easier in the long run.

Martin
===
------------------------------------------------------
Martin Knoblauch
email: knobi@knobisoft.de or knobi@rocketmail.com
www:   http://www.knobisoft.de
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: C++ definition of NULL

[Doug Semler]

----- Original Message -----
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>
Cc: Doug Semler <doug@seaspace.com>; Chad Gatesman <chadg@redrose.net>;
Jason Merrill <jason@cygnus.com>; <egcs@cygnus.com>
Sent: Tuesday, March 02, 1999 11:37 PM
Subject: Re: C++ definition of NULL


>On Mar  3, 1999, Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>
wrote:
>
>> NULL is *not* a pointer. NULL is _convertible_ to pointer type. More
>> explicitly, the C++ Standard says:
>
>> 4.10/1
>> ---
>>   A null pointer constant is na integral expression (5.19) rvalue of
>>   integer type that evaluates to zero.
>> ---

Damn, this one section is confusing....the way I've always read it is that
NULL is a macro to a null pointer constant (18.1.4) (which may be 0
or 0L)

A Null pointer constant is a constant rvalue integral *expression*  which
evaluates to 0.
 The Null pointer value (the value of the expression) can be converted to a
cv-qualified type.
 The conversion from the expression is one
 step. So any constant integral rvalue of 0 can be a null pointer constant.

So the way I read the standard, the type of a null pointer constant is
a pointer type of pointer to destination's cv-qualified type.

eg:
int *a = NULL ;   // NULL has type int *
int a = NULL;    // Error: cannot implicitly convert pointer type to int

Right?????


>
>> So NULL is of integer type. Exactly wich one is implementation-defined.
>
>Actually, it needs not be an integer type; the definition
>
>enum __NULL_type { __null = 0 };
>#define NULL __null
>
>is a valid one, because integral expressions may involve enumerators.

Re: C++ definition of NULL

[Doug Semler]

(Sorry about this follow up but....)

I meant to sea continuing on....NULL only has to be a constant
rvalue which evaluates to an integral value 0....

I could define it as (((((796+372)-345+38))*(562-131+456)).....

you get the idea :)


>
>----- Original Message -----
>From: Chad Gatesman <chadg@redrose.net>
>To: Jason Merrill <jason@cygnus.com>
>Cc: <egcs@cygnus.com>
>Sent: Tuesday, March 02, 1999 9:10 PM
>Subject: Re: C++ definition of NULL
>
>
>>Jason Merrill wrote:
>>
>>>  > I am currently porting a very large library that depends on the
>passing
>>>  > of NULL into parameters declared as long int.
>>>
>>>  > egcs appears to define NULL as __null which is a builtin symbol that
>>>  > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL
>to
>>>  > a long int parameter without casting it.
>>>
>>> Why would you want to?  Conceptually, NULL is a pointer value.
>>
>>I see what you are saying, but unfortunately, this is not my code.  I am
>>mearly porting it.  And, technically, it should work since the standard
>says
>>NULL should be a 0 or 0L
>
>
>Correct ,me if I'm wrong, but the standard says NULL is implementation
>defined, with
>(footnoted) possible values being 0 or 0L but not (void *)0
>
>You should cast, you shouldn't implicitely convert pointers to integers any
>more.... :)
>---
>Doug Semler                       | doug@seaspace.com
>SeaSpace Corporation              | Garbage In -- Gospel Out
>Least Senior Software Developer;  | Minister of things to do Next Quarter
>Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
>A closed mind is a terrible thing | Bus Error (passengers dumped)
>
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.12
>GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
>N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
>R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
>------END GEEK CODE BLOCK------
>
>
>

Re: C++ definition of NULL

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Mar  3, 1999, "Doug Semler" <doug@seaspace.com> wrote:

> So the way I read the standard, the type of a null pointer constant is
> a pointer type of pointer to destination's cv-qualified type.

> eg:
> int *a = NULL ;   // NULL has type int *
> int a = NULL;    // Error: cannot implicitly convert pointer type to int

> Right?????

Nope.  Since NULL is an integral expression, it can be converted to
int, so there's no error above.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: C++ definition of NULL

[Alan Lehotsky]

This has long since gone off topic.  Move it to comp.lang.c++, please!

Re: C++ definition of NULL

[Jason Merrill]

>>>>> Doug Semler <doug@seaspace.com> writes:

 > A Null pointer constant is a constant rvalue integral *expression*  which
 > evaluates to 0.
 >  The Null pointer value (the value of the expression) can be converted to a
 > cv-qualified type.
 >  The conversion from the expression is one
 >  step. So any constant integral rvalue of 0 can be a null pointer constant.

 > So the way I read the standard, the type of a null pointer constant is
 > a pointer type of pointer to destination's cv-qualified type.

No.  How would you write that?  The type of a null pointer constant is the
type of the integral expression.

Jason

Re: C++ definition of NULL

[Doug Semler]

----- Original Message -----
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>
Cc: Doug Semler <doug@seaspace.com>; Chad Gatesman <chadg@redrose.net>;
Jason Merrill <jason@cygnus.com>; <egcs@cygnus.com>
Sent: Tuesday, March 02, 1999 11:37 PM
Subject: Re: C++ definition of NULL


>On Mar  3, 1999, Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr>
wrote:
>
>> NULL is *not* a pointer. NULL is _convertible_ to pointer type. More
>> explicitly, the C++ Standard says:
>
>> 4.10/1
>> ---
>>   A null pointer constant is na integral expression (5.19) rvalue of
>>   integer type that evaluates to zero.
>> ---

Damn, this one section is confusing....the way I've always read it is that
NULL is a macro to a null pointer constant (18.1.4) (which may be 0
or 0L)

A Null pointer constant is a constant rvalue integral *expression*  which
evaluates to 0.
 The Null pointer value (the value of the expression) can be converted to a
cv-qualified type.
 The conversion from the expression is one
 step. So any constant integral rvalue of 0 can be a null pointer constant.

So the way I read the standard, the type of a null pointer constant is
a pointer type of pointer to destination's cv-qualified type.

eg:
int *a = NULL ;   // NULL has type int *
int a = NULL;    // Error: cannot implicitly convert pointer type to int

Right?????


>
>> So NULL is of integer type. Exactly wich one is implementation-defined.
>
>Actually, it needs not be an integer type; the definition
>
>enum __NULL_type { __null = 0 };
>#define NULL __null
>
>is a valid one, because integral expressions may involve enumerators.

Re: C++ definition of NULL

[Marc Girod]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

Per> On the other hand, using NULL as the null pointer is sanctioned
Per> by common sense, tradition, helps code readability, and (using
Per> some name or other) is what every other high-level language
Per> providing pointers does.

Well, I am lacking common sense and saying "no thanks" to this kind of
help in readability with Martin.
And probably standing on my head while looking at the heights.

I agree with your mention of tradition though.

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com

Re: C++ definition of NULL

[Chad Gatesman]

Jason Merrill wrote:

> Chad, please try compiling with -ansi.  In 1.1, when -ansi is on, __null is
> of integral type.

This breaks all kinds of code, and removes internal defines that the code
depends on to determine the platform I am on.


Martin Knoblauch wrote:

>  Hmm. Are you now assuming that sizeof(long) == sizeof(void *)?
> What if the IA64 Unixes come out as LL-P-64, leaving "long" at
> 32 bit to make porting M$ legacy software easier? While it is
> a hassle in the short term, explicitely casting will make things
> easier in the long run.

The code is assuming this, unfortunately.  But it has been common practice (and
I believe it will remain) that long is the size of a pointer.  The code is
already ported to 8 platforms (including 64-bit), and this hasn't been an
issue.


Thomas Kunert wrote:

> Since NULL is a constant casting it is rather dumb. Your usage of that
> constant is not intended by the standard and hence misguiding. Instead
> of casting I'd replace any `NULL' with `0'. This is easily done using
> something like sed. Then your code will compile and becomes more
> readable.

As I have said before, this is existing code (not mine), and even though it is
not so "proper" (which I agree), it should still work if NULL is defined as the
standard suggests.


"Martin v. Loewis" wrote:

> Yes, it looks like this is a bug in egcs 1.1.1. I haven't checked
> whether the bug is still present in 1.1.2, however, it appears it is
> fixed in the current development snapshots (egcs-2.93.10).

This has been pointed out to me, and I am glat to hear this.  Do we have any
idea when it would make it into a regular release?  The following version
(1.1.3 or 1.2 (which ever comes first))?

> From that, it appears you have a number of options:
>
> a) Replace all occurences of NULL with 0. This is IMHO the Right Thing
>    (tm), because the NULL symbol is an ugly hack, and just there for
>    backwards compatibility.
>
> b) Use a more current egcs release. You've indicated that you need
>    production quality, so this is probably not an option.
>
> c) Change your installation of egcs to define NULL in whatever way you
>    think is appropriate.

From the looks of it there are only about 10 system headers that define
__need_NULL and then include stddef.h.  For a workaround, for now, I think I am
going to try to include all this headers all in one spot the redefine NULL
afterwards.  NULL should not get redefined there after assuming all those 10
system headers are protected by #ifndefs for multiple inclusion.

But my biggest consern was for the people that would be using the library.  As
standard practice of the API within the library it is assumed you can pass NULL
to them.  This is mostly because the parameter in question has been mostly
designed to handle both pointers and values.  I agree, this was not the best
approach to do this, but technically, it should work.

Thanks for all the help,
Chad Gatesman

Re: C++ definition of NULL

[Jason Merrill]

Chad, please try compiling with -ansi.  In 1.1, when -ansi is on, __null is
of integral type.

Jason

Re: C++ definition of NULL

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On Mar  3, 1999, Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> wrote:

> NULL is *not* a pointer. NULL is _convertible_ to pointer type. More
> explicitly, the C++ Standard says:

> 4.10/1
> ---
>   A null pointer constant is na integral expression (5.19) rvalue of
>   integer type that evaluates to zero.
> ---

> So NULL is of integer type. Exactly wich one is implementation-defined.

Actually, it needs not be an integer type; the definition

enum __NULL_type { __null = 0 };
#define NULL __null

is a valid one, because integral expressions may involve enumerators.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: C++ definition of NULL

[Martin Knoblauch]

---Chad Gatesman <chadg@redrose.net> wrote:
>
> Doug Semler wrote:
> 
> > You should cast, you shouldn't implicitely convert pointers to
integers any
> > more.... :)
> 
> The standard does not say this.  If NULL is defined as they
suggested, one
> would be able to be implicitly casted to a long.  I would hate to
have to go
> thru 1 million+ lines of code just to cast all occurances of NULL
and force
> users of the library to do the same.
> 

 Hmm. Are you now assuming that sizeof(long) == sizeof(void *)?
What if the IA64 Unixes come out as LL-P-64, leaving "long" at
32 bit to make porting M$ legacy software easier? While it is
a hassle in the short term, explicitely casting will make things
easier in the long run.

Martin
===
------------------------------------------------------
Martin Knoblauch
email: knobi@knobisoft.de or knobi@rocketmail.com
www:   http://www.knobisoft.de
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: C++ definition of NULL

[Gabriel Dos Reis]

>>>>> Doug Semler <doug@seaspace.com> wrote:

[...]


> Correct ,me if I'm wrong, but the standard says NULL is implementation
> defined, with
> (footnoted) possible values being 0 or 0L but not (void *)0

right.

> You should cast, you shouldn't implicitely convert pointers to integers any
> more.... :)


NULL is *not* a pointer. NULL is _convertible_ to pointer type. More
explicitly, the C++ Standard says:

4.10/1
---
  A null pointer constant is na integral expression (5.19) rvalue of
  integer type that evaluates to zero.
---

So NULL is of integer type. Exactly wich one is implementation-defined.

-- Gaby

Re: C++ definition of NULL

[Chad Gatesman]

Doug Semler wrote:

> Correct ,me if I'm wrong, but the standard says NULL is implementation
> defined, with
> (footnoted) possible values being 0 or 0L but not (void *)0

This is correct.

> You should cast, you shouldn't implicitely convert pointers to integers any
> more.... :)

The standard does not say this.  If NULL is defined as they suggested, one
would be able to be implicitly casted to a long.  I would hate to have to go
thru 1 million+ lines of code just to cast all occurances of NULL and force
users of the library to do the same.

Chad Gatesman

Re: C++ definition of NULL

[Doug Semler]

(Sorry about this follow up but....)

I meant to sea continuing on....NULL only has to be a constant
rvalue which evaluates to an integral value 0....

I could define it as (((((796+372)-345+38))*(562-131+456)).....

you get the idea :)


>
>----- Original Message -----
>From: Chad Gatesman <chadg@redrose.net>
>To: Jason Merrill <jason@cygnus.com>
>Cc: <egcs@cygnus.com>
>Sent: Tuesday, March 02, 1999 9:10 PM
>Subject: Re: C++ definition of NULL
>
>
>>Jason Merrill wrote:
>>
>>>  > I am currently porting a very large library that depends on the
>passing
>>>  > of NULL into parameters declared as long int.
>>>
>>>  > egcs appears to define NULL as __null which is a builtin symbol that
>>>  > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL
>to
>>>  > a long int parameter without casting it.
>>>
>>> Why would you want to?  Conceptually, NULL is a pointer value.
>>
>>I see what you are saying, but unfortunately, this is not my code.  I am
>>mearly porting it.  And, technically, it should work since the standard
>says
>>NULL should be a 0 or 0L
>
>
>Correct ,me if I'm wrong, but the standard says NULL is implementation
>defined, with
>(footnoted) possible values being 0 or 0L but not (void *)0
>
>You should cast, you shouldn't implicitely convert pointers to integers any
>more.... :)
>---
>Doug Semler                       | doug@seaspace.com
>SeaSpace Corporation              | Garbage In -- Gospel Out
>Least Senior Software Developer;  | Minister of things to do Next Quarter
>Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
>A closed mind is a terrible thing | Bus Error (passengers dumped)
>
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.12
>GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
>N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
>R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
>------END GEEK CODE BLOCK------
>
>
>

Re: C++ definition of NULL

[Doug Semler]

----- Original Message -----
From: Chad Gatesman <chadg@redrose.net>
To: Jason Merrill <jason@cygnus.com>
Cc: <egcs@cygnus.com>
Sent: Tuesday, March 02, 1999 9:10 PM
Subject: Re: C++ definition of NULL


>Jason Merrill wrote:
>
>>  > I am currently porting a very large library that depends on the
passing
>>  > of NULL into parameters declared as long int.
>>
>>  > egcs appears to define NULL as __null which is a builtin symbol that
>>  > treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL
to
>>  > a long int parameter without casting it.
>>
>> Why would you want to?  Conceptually, NULL is a pointer value.
>
>I see what you are saying, but unfortunately, this is not my code.  I am
>mearly porting it.  And, technically, it should work since the standard
says
>NULL should be a 0 or 0L


Correct ,me if I'm wrong, but the standard says NULL is implementation
defined, with
(footnoted) possible values being 0 or 0L but not (void *)0

You should cast, you shouldn't implicitely convert pointers to integers any
more.... :)
---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+
N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+
R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++**
------END GEEK CODE BLOCK------

Re: C++ definition of NULL

[Chad Gatesman]

David Edelsohn wrote:

>         You do not mention which release of EGCS you are using, but I
> presume that you are refering to egcs-1.1.X and not the development
> snapshots.  There is a bug related to this in egcs-1.1 which is fixed in
> the development sources.  Unfortunately it looks like the fix is too
> involved to include in an egcs-1.1 update.

Excuse me.  That was pretty thoughtless of me.  I'm using egcs-1.1.1.  Do
you know what all the fix intailed or how I can easily find out?  Would it
be in egcs-1.1.2?  I really don't want to move our production compiler to a
snapshot ;)

Thanx,
Chad Gatesman

Re: C++ definition of NULL

[David Edelsohn]

	You do not mention which release of EGCS you are using, but I
presume that you are refering to egcs-1.1.X and not the development
snapshots.  There is a bug related to this in egcs-1.1 which is fixed in
the development sources.  Unfortunately it looks like the fix is too
involved to include in an egcs-1.1 update.

David

C++ definition of NULL

[Chad Gatesman]

I am currently porting a very large library that depends on the passing
of NULL into parameters declared as long int.

egcs appears to define NULL as __null which is a builtin symbol that
treats NULL as `{unknown type} *'.  Therefore, I cannot pass in NULL to
a long int parameter without casting it.

e.g.

#include <stdlib.h>

void func(long i)
{
}

void func(int a, int b)
{
}

void main()
{
    func(NULL);
}

> g++ -Wall -c t.cxx
t.cxx:12: warning: return type for `main' changed to `int'
t.cxx: In function `int main(...)':
t.cxx:13: no matching function for call to `func (NULL)'
t.cxx:4: candidates are: func(long int)
t.cxx:8:                 func(int, int)


If this is the case, how can I disable this behavior and use NULL as a
typical 0.  I don't want to have to put a -DNULL=0 in my compile lines,
and I can't  assume that just taking care of it with a redefine in one
of my headers would take care of it, because someone using the library
could end up getting the NULL redefined back to __null.  It would be
nice if the definition in stddef.h was as follows:

#ifndef NULL
#define NULL __null
#endif

Instead of:

#undef
#define NULL __null

Is there a reason it is done this way?  Since it is this why, it
prevents me from redefining it after it is defined the first time and
assuming it will remain that way.

Another thing.  Should this behavior really exist?  The standard states
that NULL should be defined as 0 or 0L.

Suggestions on a good workaround would be nice, but I think this is not
the way NULL should be implemented and it should be reconsidered
defining it as 0.

Thanks,
Chad Gatesman