I (David R Tribble <david.tribble@central.beasys.com>) wrote:
>> And here's yet one more argument for having a 'null' keyword in C/C++.
>> (This was discovered accidentally the other day by a co-worker.)

Hyman Rosen <uunet!jyacc!calumny!hymie@ncar.UCAR.EDU> asked:
> Did it cause a bug, or just a curiosity?

It caused a bug.  The code looked something like this (bear in mind that
it was accidentally coded this way):

    p = new(nothrow) Foo();
    if (p == NULL  ||  p != Foo::OKAY)  // OKAY is an enum zero
        error();

Thus if the 'new' executes correctly, the 'if' detects an error if 'p'
is null or is not zero (i.e., not null).  It's a bug which compiles
without warnings.

>> I patiently await a response claiming that this is a good thing.

> But you don't have to use these constructs. What harm does it do
> if they exist?

Well, when they aren't caught by the compiler and it results in bugs,
it's a bad thing.  A good language and a good compiler ought to catch
some accidental programming bugs like the one above.

--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Support the anti-Spam amendment, join at http://www.cauce.org/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <t7zppm9zpw.fsf@calumny.jyacc.com>, Hyman Rosen <uunet!jyacc!
calumny!hymie@ncar.UCAR.EDU> writes

...snip...

>
>But you don't have to use these constructs. What harm does it do
>if they exist?

Some people will use "these constructs" in the kind of exuberant fashion
that that means torture for the rest of us when they decamp and leave us
to find their bugs.
The language should (I mean morally ought) to preserve us from them,
preferably by firing squad, or otherwise with error messages.

cf :

if (x = 3) ...;

--
Age has tought me one thing :
being old is shit
Mike Davies
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Alien wrote:
>
> I'm all for a 'null' keyword, but wonder if there isn't perhaps a gap
> in rhw language, even _with_ it.  Namely, typed nulls.

C++ already has typed nulls. You even have two ways to spell them:
Method 1:
 (char*)0
 (long*)0
 (MyClass*)0
Method 2:
 static_cast<char*>(0)
 static_cast<long*>(0)
 static_cast<MyClass*>(0)

--
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

alien@interport.net (Alien) writes:

>I'm all for a 'null' keyword, but wonder if there isn't perhaps a gap
>in rhw language, even _with_ it.  Namely, typed nulls.  For example,
>if I have the following overloaded functions:
>
>A) void foo( int i );
>B) void foo( int* pi );
>C) void foo( bool* pf );
>
>Adding a 'null' keyword disambiguates A and B by letting you pass 0 or
>null to select between them.  But how do you select between B and C?
>You can't, as far as I can tell.

Sure you can.  Pete Becker already pointed out the solution: use
`(int *)0' and `(bool *)0', or, with a `null' keyword,
`(int *)null' and `(bool *)null'.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Darron Shaffer wrote:
>
>
> My code looked something like this:
>
>         foo = new(nothrow) Foo;
>         if (foo == NULL  ||  foo != Foo::Success)
>         {
>             //  Error code
>         }
>
> It should have had: 'foo->status() != Foo::Success'
>
> The compiler had no complaints -- I had to find the typo (large typo?)
> in the debugger.

Not that you don't raise a valid point, but in this case, at least, you
have to admit that finding the bug must have taken all of five
minutes...
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

linhd@no-spam-nortel.ca wrote:
 >
 > >>>>>> "SC" == Steve Clamage <stephen.clamage@Eng.Sun.COM> writes:
 >  SC> Maybe I'm wrong about this, but given the compatibility issue, I
 >  SC> don't see how a 'null' keyword could have the right behavior and
 >  SC> not wind up being merely an alternative way to spell '0'.
 >
 > let's say my code originally is:
 >
 >         void* foo(void* p) { .... }
 >
 >         void  bar() { foo(0); ... }
 >
 > adding an overloaded `foo' will break my code (at least under most
 > compilers):
 >
 >         void* foo(void* p) { ... }
 >         int   foo(int n) { ... }
 >
 >         void  bar() { foo(0); ... }
 >
 > having a null keyword will help keeping my code working:
 >
 >         void* foo(void* p) { ... }
 >         int   foo(int n) { ... }
 >
 >         void  bar() { foo(null); ... }
 >
 > Or am I missing something ?

If that's a concern for you, then don't write foo(0). Instead, write
foo((void *)0). No keyword necessary.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Pete Becker <petebecker@acm.org> writes:

 >linhd@no-spam-nortel.ca wrote:
 > > let's say my code originally is:
 > >
 > >         void* foo(void* p) { .... }
 > >
 > >         void  bar() { foo(0); ... }
 > >
 > > adding an overloaded `foo' will break my code (at least under most
 > > compilers):
 > >
 > >         void* foo(void* p) { ... }
 > >         int   foo(int n) { ... }
 > >
 > >         void  bar() { foo(0); ... }
 > >
 > > having a null keyword will help keeping my code working:
 > >
 > >         void* foo(void* p) { ... }
 > >         int   foo(int n) { ... }
 > >
 > >         void  bar() { foo(null); ... }
 > >
 > > Or am I missing something ?
 >
 >If that's a concern for you, then don't write foo(0). Instead, write
 >foo((void *)0). No keyword necessary.

But then you have to use explicit typing.  If the two versions of `foo'
are `void foo(char *)' and `void foo(int)', then you would have to write
`foo((char *)0)'.  Explicit typing is a pain.  I'd much prefer the
compiler to infer the appropriate pointer type.  Scattering lots of
casts throughout the code is distracting, harms the readability of the
code, and makes the genuinely dangerous casts stand out less.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

And here's yet one more argument for having a 'null' keyword in C/C++.
(This was discovered accidentally the other day by a co-worker.)

As currently defined, any integral constant expression with the value zero
can be used as a null pointer constant.  This includes the obvious '0'
constant, as well as obscure but equally legal constants such as '(3-3)'.

It also includes all constants that can be promoted to int, including
bool and enum.  For example, the following code is legal and will not
produce compilation errors, in both C and C++:

    enum Fubar  { OKAY = 0 };

    void bar()
    {
        char *  p;

        p = ...;        // new() or malloc()

        if (!p) ...             // ptr converts to bool
        if (p == 0) ...         // int converts to ptr
        if (p == (3-3)) ...     // int converts to ptr
        if (p == OKAY) ...      // enum converts to int converts to ptr
        if (p == false) ...     // bool converts to int converts to ptr

        p = 0;          // int converts to ptr
        p = (3-3);      // int converts to ptr
        p = OKAY;       // enum converts to int converts to ptr
        p = false;      // bool converts to int converts to ptr
    }

[See C++ CD2 sections 4.5 and 4.10, and ANSI/ISO C section 6.2.3.3.]

I patiently await a response claiming that this is a good thing.

--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Support the anti-Spam amendment, join at http://www.cauce.org/
Send junk to: postmaster@agis.net mrchig@easynet.co.uk
 emailer@qlink2info.com simrem@answerme.com markdan3@earthlink.net
 clover@earthfriends.com office@savetrees.com abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble <david.tribble@central.beasys.com> writes:
> And here's yet one more argument for having a 'null' keyword in C/C++.
> (This was discovered accidentally the other day by a co-worker.)

Did it cause a bug, or just a curiosity?

> As currently defined, any integral constant expression with the value zero
> can be used as a null pointer constant.  This includes the obvious '0'
> constant, as well as obscure but equally legal constants such as '(3-3)'.
> It also includes all constants that can be promoted to int, including
> bool and enum.
>
> I patiently await a response claiming that this is a good thing.

But you don't have to use these constructs. What harm does it do
if they exist?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

--Multipart_Wed_Sep_10_13:36:10_1997-1
Content-Type: text/plain; charset=US-ASCII

Hyman Rosen <uunet!jyacc!calumny!hymie@ncar.UCAR.EDU> writes:

> David R Tribble <david.tribble@central.beasys.com> writes:
> > And here's yet one more argument for having a 'null' keyword in C/C++.
> > (This was discovered accidentally the other day by a co-worker.)
>
> Did it cause a bug, or just a curiosity?
>

My code looked something like this:


 foo = new(nothrow) Foo;
 if (foo == NULL  ||  foo != Foo::Success)
 {
     //  Error code
 }

It should have had: 'foo->status() != Foo::Success'

The compiler had no complaints -- I had to find the typo (large typo?)
in the debugger.


> >
> > I patiently await a response claiming that this is a good thing.
>
> But you don't have to use these constructs. What harm does it do
> if they exist?

More errors caught (you hope) in testing, rather than at compile time.



--Multipart_Wed_Sep_10_13:36:10_1997-1
Content-Type: text/plain; charset=US-ASCII

Darron J Shaffer <Darron.Shaffer@beasys.com>
Sr. Software Engineer
BEA Systems
(972) 738-6137


--Multipart_Wed_Sep_10_13:36:10_1997-1--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble wrote:
>
> And here's yet one more argument for having a 'null' keyword in C/C++.
> (This was discovered accidentally the other day by a co-worker.)
>
> As currently defined, any integral constant expression with the value zero
> can be used as a null pointer constant.

> I patiently await a response claiming that this is a good thing.

Well, okay.
This is a good thing.  It allows a bunch of existing C++ and C code to
work.  Since I'm not in the habit of assigning intergral expressions,
enumerators, or boolean to pointers, it doesn't particularly bother me.

                        ]
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>And here's yet one more argument for having a 'null' keyword in C/C++.
>(This was discovered accidentally the other day by a co-worker.)
>
>As currently defined, any integral constant expression with the value zero
>can be used as a null pointer constant.  This includes the obvious '0'
>constant, as well as obscure but equally legal constants such as '(3-3)'.
>
>It also includes all constants that can be promoted to int, including
>bool and enum.  For example, the following code is legal and will not
>produce compilation errors, in both C and C++:

I'm all for a 'null' keyword, but wonder if there isn't perhaps a gap
in rhw language, even _with_ it.  Namely, typed nulls.  For example,
if I have the following overloaded functions:

A) void foo( int i );
B) void foo( int* pi );
C) void foo( bool* pf );

Adding a 'null' keyword disambiguates A and B by letting you pass 0 or
null to select between them.  But how do you select between B and C?
You can't, as far as I can tell.  But I can imagine a typed null, such
as bool::null and int::null.  The default null would be equivalent to
void::null, and this class-scoping would not normally be necessary
except when there's an ambiguity to clear up, as above.

Is this an old idea?  And, if so, has it been beaten around until its
flaws have been discovered?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble <david.tribble@central.beasys.com> writes:

> And here's yet one more argument for having a 'null' keyword in C/C++.
> (This was discovered accidentally the other day by a co-worker.)

We have heard all the arguments at least one hundred times.

> As currently defined, any integral constant expression with the value zero
> can be used as a null pointer constant.  This includes the obvious '0'
> constant, as well as obscure but equally legal constants such as '(3-3)'.

True

> It also includes all constants that can be promoted to int, including
> bool and enum.  For example, the following code is legal and will not
> produce compilation errors, in both C and C++:

There no false in C, but the enum is valid in C.

>     enum Fubar  { OKAY = 0 };

>         if (p == OKAY) ...      // enum converts to int converts to ptr
>         if (p == false) ...     // bool converts to int converts to ptr

These two aren't valid.

>         p = OKAY;       // enum converts to int converts to ptr
>         p = false;      // bool converts to int converts to ptr

Nor these.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Gary Mussar <mussar@nortel.ca> quoted me:
>
>David R Tribble wrote:
>> I proposed the very same thing, too, on the comp.std.c++ a few months
>> ago (I think you mentioned your proposal then, too).  Most of the
>> responses opposed to it were weak, as to be expected.  I personally (as
>> a programmer familiar with compiler writing) see either solution, a
>> 'null' keyword or '((void*)0)', as being easy to do (the compiler
>> already does it for 0) and readily acceptable to programmers (whether
>> they use it or not).

He then points out an apparent problem:
>
> Given:
>
> void foo(void*){}
> void foo(int*){}
>
> void bar() { foo(null);}
>
> I want the compiler to complain about an ambiguous overload. I don't
> want it to quietly pick the void* version because someone thought
> that all null pointers are void*. We had some yahoo #define NULL
> to be ((void*)0) and it cause a number of problems in our code
> (we've only got a few million lines of C++ to maintain).

This is a misunderstanding James Kanze's (and my) original proposal.
We suggested that the expression '((void*)0)' be treated as a special case,
i.e., as a null pointer constant, just like 0 is today.  But it has no type
other than 'pointer', i.e., it can be assigned or compared to *any* pointer
type, not just 'void*'.

Given this usage of a null constant, your example would fail to compile
because it's ambiguous; 'null' has no specific pointer type.  To
disambiguate it, you would have to cast it to the appropriate pointer type
that you wanted:
     void bar() { foo((int*)null); }
or:  void bar() { foo((void*)null); }

A compiler would have no trouble knowing that an extra '(void*)' cast
on 'null' means that you want a null pointer of type 'void*'.  But a
bare 'null' with no typecast means simply 'untyped null pointer constant'.

We wanted to replace the use of 0 (an integer constant) with something
more resembling a pointer.  The compiler still has to treat '((void*)0)'
as a special case, like it has to do for 0 now.  But by using a constant
that actually resembles a pointer, the chances for ambiguity are lessened
(such as if your example also had a 'void foo(int) {}' function).
And programmers can write more readable code using the 'null' macro (or
keyword) rather than 0.

> If there was a keyword for null it shouldn't have anything to do
> with void*.

The original proposal for the 'null' macro meets this criterion.
Personally, I prefer a keyword.  But the original proposal was a way to
introduce the concept of a real 'null pointer constant' into C/C++ without
adding too much baggage to the language.


C++, the PL/1 of the 90s.
--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk
 emailer@qlink2info.com simrem@answerme.com office@canma.dyn.ml.org
 markdan3@earthlink.net clover@earthfriends.com office@savetrees.com
 abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble wrote:
>
> David R Tribble (I) responded (via private email): ...
> >
> >|> Yes, I've had my share of proposals that were rejected also.  The quality
> >|> (reasonableness) of the proposals don't seem to sway their acceptability.

I don't believe that is a fair comment. Persons A and B might think
a proposal has merit and little or no disadvantage, but that doesn't
mean that the majority of the C++ Committee will agree. You can call
that politics if you want, but it also might be that persons A and B
are simply wrong. (I make this point without reference to any particular
proposal.)

> kanze@gabi-soft.fr (J. Kanze) continued (via private email):
> >
> > Well, my proposal [for a null keyword] wasn't too late; I made it four or five years ago.
> > Formally, as an ANSI member.  Fergus Henderson did a prototype proof of
> > concept in g++, and Dag Bruck (the Swedish rep., and co-author of the
> > bool proposal) championed it at the meeting.
> >
> > I suspect that politics does play a part.  IMHO: my proposal was simpler
> > than bool, and fit into the language just as well.  On the other hand,
> > having Andy Koenig as co-author certainly gave the bool proposal a major
> > advantage.
>
> Well, I *suppose* one could argue that 'bool' was needed more than 'null'.
> On the other hand, it could be argued that C/C++ programs can be written
> without either; but is the programmer better off without them (both)?

I don't think the two topics are comparable.

C and C++ lacked a proper bool type. In C the lack is inconvenient
primarily because you can't easily tell when an integer value is
being used as a boolean. In C++ the lack is more keenly felt because
you logically need to be able to overload functions on a boolean type
and there is no workaround. (People sometimes suggested defining a
boolean enum or class, but neither approach had the right semantics.)

The bool type was added to C++ in such a way that it was a true type
built into the language, and old code still worked but reflected new
language semantics. For example, a comparison expression now has type
bool, not type int, and fits in with purely boolean operations.
Condition expressions (in 'if' and 'for' statements) are type bool,
converted as necessary from their actual type.

I always thought it was a serious oversight that C lacked a 'null'
keyword. But what are the advantages of adding it to C++? For
compatibility with C code and millions of lines of existing C++
code, the old rules about literal 0 must be kept. If 'null'
were adopted and you wrote a program using it, you could later
substitute '0' for 'null' everywhere, and I don't think it would
affect the program. That is why I didn't support any proposal
to add a 'null' keyword, and I suspect many other people felt the
same way. It's a small and simple language change, it's costs are
not large, but it yields almost no benefit.

Maybe I'm wrong about this, but given the compatibility issue, I
don't see how a 'null' keyword could have the right behavior and
not wind up being merely an alternative way to spell '0'.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>David R Tribble (I) wrote:
>>
>> Well, I *suppose* one could argue that 'bool' was needed more than 'null'.
>> On the other hand, it could be argued that C/C++ programs can be written
>> without either; but is the programmer better off without them (both)?

Steve Clamage <stephen.clamage@Eng.Sun.COM> responded:
>
> I don't think the two topics are comparable.

Well, the two topics are comparable.  What were you using for 'false'
before we had 'bool'?

> C and C++ lacked a proper bool type. In C the lack is inconvenient
> primarily because you can't easily tell when an integer value is
> being used as a boolean.

Well, as you say, it's inconvenient.  In your sentence above, just change
"boolean" to "null pointer" and you'll see my point.

> In C++ the lack is more keenly felt because
> you logically need to be able to overload functions on a boolean type
> and there is no workaround.

And you also need to overload functions with both 'int' and 'Type*' args.
This creates ambiguities when you want to pass 'null' (as currently
defined as '0') to them.

> I always thought it was a serious oversight that C lacked a 'null'
> keyword. But what are the advantages of adding it to C++?

Because it would plug a semantic hole in the language.  It would remove
ambiguity in cases where '0' can't be chosen between 'Type*' and 'int'
function arguments.  And it would establish that (eventually, some day)
'0' is one thing only: an integer zero constant, not 'false' and not
'null'.

In fact, the lack of a 'null' is worse for C++ than for C, because
using '((void*)0)' as null works in C.  But not in C++.

> For compatibility with C code and millions of lines of existing C++
> code, the old rules about literal 0 must be kept.

Yes, I agree.

But them we mark the use of '0' as a null pointer constant as deprecated
practice.  In 5 or 8 years when we get to the next revision of C++,
people will have had time to adjust.

> If 'null' were adopted and you wrote a program using it, you could later
> substitute '0' for 'null' everywhere, and I don't think it would
> affect the program. That is why I didn't support any proposal
> to add a 'null' keyword, and I suspect many other people felt the
> same way. It's a small and simple language change, it's costs are
> not large, but it yields almost no benefit.

Except for the benefits of more readable code, no ambiguous calls, and a
tighter typing system.  Without 'null', C++ has a hole in it.  A small
hole, yes, but still a hole.

> Maybe I'm wrong about this, but given the compatibility issue, I
> don't see how a 'null' keyword could have the right behavior and
> not wind up being merely an alternative way to spell '0'.

Except that 'null' isn't an integer.  You seem to be saying that it's okay
that '0' has only one spelling but two alternative meanings (an integer
zero constant and a null pointer constant).  We've gotten rid of one of
the meanings of '0' (false), why not get rid of the other (null)?

Sorry, but no counterargument given so far convinces me that 'null' is
a bad thing.  Or expensive.  Or not worth having.


--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk
 emailer@qlink2info.com simrem@answerme.com office@canma.dyn.ml.org
 markdan3@earthlink.net clover@earthfriends.com office@savetrees.com
 abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@Eng.Sun.COM> writes:

>I always thought it was a serious oversight that C lacked a 'null'
>keyword. But what are the advantages of adding it to C++? For
>compatibility with C code and millions of lines of existing C++
>code, the old rules about literal 0 must be kept.

Yes, they must be kept for a long time (not necessarily forever), but
compilers can issue optional warnings about use of literal 0 as a null
pointer.  So even though the old rules must remain, if there was a
`null' keyword then I wouldn't have to rely on them.  I could clean up
my code to never use literal 0 as a null pointer, just as I have
cleaned up my old C code to be const-correct, etc.

>If 'null'
>were adopted and you wrote a program using it, you could later
>substitute '0' for 'null' everywhere, and I don't think it would
>affect the program.

It would certainly affect the _readability_ of the program!

It might also affect the behaviour in cases where there are calls
to overloaded functions.  For example, if you have

 void foo(int);
 void foo(char *);

then `foo(0)' calls `foo(int)', whereas `foo(null)' ought to call
`foo(char *)'.

And looking only at working programs doesn't show the advantages
of a `null' keyword.  One of the advantages is better type checking.
For example,

 int x;
 // ... lots of code in between
 x = NULL;

might compile fine if `NULL' is 0, but if NULL is `null', then
you should get at least a warning.

>Maybe I'm wrong about this, but given the compatibility issue, I
>don't see how a 'null' keyword could have the right behavior and
>not wind up being merely an alternative way to spell '0'.

I don't think the compatibility issues require supporting code
such as `int x = NULL'.  Such code may happen to work under the
current rules, but it is fundamentally broken as far as I am concerned.
I think it would be good to get a warning for that sort of code.
And as has been pointed out by others in this thread, such warnings
would indeed catch real bugs.

Similarly, changing the behaviour of `foo(NULL)' to call `foo(char *)'
in preference to `foo(int)' would not break any well-written code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

|I would have thought that getting a compiler to treat ((void *)0) as
|something special would have been fairly difficult.  I would think
|that a keyword for null or some compiler specific attribute (like
|gcc's attributes) would be the most likely way to be able to
|implement this. But I'm not a compiler writer.

It's not really difficult (and I used to be a compiler writer).  C
compilers already have to recognize and track ((void *)0) as
something special because it is a null pointer constant, just like 0,
and the C standard has places that require you (as a compiler) to
know whether or not you're dealing with a null pointer constant.

In fact, they will also recognize ((void *)(3 * 3 - 9)) as a null
pointer constant (just as a C++ compiler will recognize (3 * 3 - 9)
as a null pointer constant), because of the way the standard defines
it, but I suspect very few compilers will ever see this particular
version. :-)

As an aside, though it's not a legal definition for NULL in C++, in C
it's better at catching mis-uses, which may explain why the `yahoo'
in your earlier post thought it was a good idea (if he/she was
concerned primarily with C).  Of course since the historical mis-use
of NULL in C has been high, it _still_ might not be a good idea if
you don't want to fix them all...
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Mark@mWilden.com wrote:
>I'd hate to give up the flexibility of treating 0 as a special pointer
>value just to handle this rare situation.

Flexibility?  What about readability?  You missed my point; 0 is an int,
not a pointer.  It looks like an int, so it should be treated like an int.

>> Adding a 'null' keyword to C++ is a trivial thing to do, and it
>> closes a semantic hole in the language.  Why not do it now, when extra
>> keywords are already being added to the language?
>
>Because as you mentioned, it would only be of use if 0 were disallowed
>as a valid pointer value, which would break 99% of existing C++ code.

It would break 0% of my code.  But then, I distinguish between ints, bools,
and pointers in my code.  Most C programmers, apparently, are too lazy to
do this, and the language, unfortunately, doesn't care.  This is not
flexibility, it's bad programming, playing fast and loose with the typing
mechanism.  For all its power and complexity, C++ still encourages bad
programming.


C++, the PL/1 of the 90s.
--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk
 emailer@qlink2info.com simrem@answerme.com office@canma.dyn.ml.org
 markdan3@earthlink.net clover@earthfriends.com office@savetrees.com
 abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I <david.tribble@central.beasys.com> wrote:
>> Most C programmers, apparently, are too lazy to
>> do this [use a 'null' keyword instead of 0], and the language,
>> unfortunately, doesn't care.
>> This is not flexibility, it's bad programming, playing
>> fast and loose with the typing mechanism.  For all its
>> power and complexity, C++ still encourages bad programming.

Nathan Myers <ncm@cantrip.org> responded:
> ...
> Second, do you really think pissing and moaning makes life more
> fun for anybody?  Does it make life more fun for you?  (These are
> not rhetorical questions, though I don't expect an answer.)

Pissing and moaning about deficiencies in languages and libraries is
what prompts people to innovate and extend.  If we were all satisfied
with what's available, no one would invent anything new.  We'd all be
using FORTRAN and IBM/370 macro assembler and loving it.

> C++ is complex, it's powerful, and it has flaws resulting
> from its evolutionary heritage.  (Much like yourself, or myself.)
> We can have fun despite the flaws.  There are things you can do
> in C++ you can't do in any other language; maybe some day there
> will be another language as powerful, without the flaws.  When
> that happens, I'll switch.

All I ask for is to make the new edition of C++ as type-safe as Pascal.
The lack of an explicit null pointer is an embarrassing hole in the language
which allows for ambiguities.  And there are other languages as powerful
and innovative, just not as popular (e.g., Eiffel).

(And BTW, 0 is not a null pointer, it's an int constant.  It's just that
C/C++ allows it, as a special case, to be convertible into any pointer type
in certain situations.  Consider the fact that 'sizeof(0)==sizeof((void*)0)'
is false on many machines.)

I'm surprised you didn't suggest a compromise:  Add a new 'null' keyword
which is compatible with any pointer type (and only pointer types), but
continue to allow 0 to be used as a null pointer constant (and perhaps
deprecating it for the next edition of C++).  This would satisfy all of us.

C++, the PL/1 of the 90s.
--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk
 emailer@qlink2info.com simrem@answerme.com office@canma.dyn.ml.org
 markdan3@earthlink.net clover@earthfriends.com office@savetrees.com
 abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

You wrote:

> Most C programmers, apparently, are too lazy to
> do this, and the language, unfortunately, doesn't care.
> This is not flexibility, it's bad programming, playing
> fast and loose with the typing mechanism.  For all its
> power and complexity, C++ still encourages bad programming.
>
> C++, the PL/1 of the 90s.

First, surely you are aware that C++ is constrained to be
upward-compatible with C.  There are many things one would
do differently given the luxury of starting from scratch.
Bitching about C++'s C compatibility does no good for anybody.

Second, do you really think pissing and moaning makes life more
fun for anybody?  Does it make life more fun for you?  (These are
not rhetorical questions, though I don't expect an answer.)

C++ is complex, it's powerful, and it has flaws resulting
from its evolutionary heritage.  (Much like yourself, or myself.)
We can have fun despite the flaws.  There are things you can do
in C++ you can't do in any other language; maybe some day there
will be another language as powerful, without the flaws.  When
that happens, I'll switch.

Nathan Myers
ncm@cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble <david.tribble@central.beasys.com> (I) wrote:
>>
>> Well, it's simple.  If we let '((void*)0)' be NULL, i.e., 'untyped null
>> pointer constant'...

Jason Merrill <jason@cygnus.com> asked:
>
> But we can't do that.  What if I *want* a null pointer of type (void*)?
> How do I get that?

By using '(void*)null' or, equivalently, '(void*)((void*)0)'.  By itself,
'(void*)0' would be recognized as 'untyped null pointer' and not as a
normal typecast expression.  Adding another cast to it, however, would be
recognized as a typecast expression (casting null to a specific pointer
type).  (Think about it operating as if '(void*)0' compresses down into
a 'null' constant/identifier/keyword.)

> Making (void*)0 be untyped is an unnecessary special
> case, and there are too many of those in the language already.  A keyword
> is much cleaner.

I agree that a keyword is cleaner, and that's what I prefer.  But remember
that '0' is already a special case; changing it so that '(void*)0' is the
special case instead yields no net change in the number of special cases.

Bear in mind that the '(void*)0' proposal was made as a concession to
those who don't want a whole new keyword.  Presumably, there are those
who think that adding a new 'null' keyword would be harder to do than
handling '(void*)0' as a special case.  I personally think it's about the
same amount of work (i.e., minimal) in either case.


[See <http://www.sfgoth.com/term/> for news about today's date.]
--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I think the committee would be hesitant to adopt a keyword null on
the 'we don't want another keyword' excuse. In this case, I think
the excuse is valid since many people have already defined their own
'null's. Also, semantics for the new keyword would have to be worked
out. (Not a big task, but still a task).

Here is a definition for 'null' which I developed based on previous
discussion in this newsgroup. I think it should be placed in namespace
std, so it doesn't conflict with others people definitions of null. It
would have to be coupled with the requirement (or warning diagnostic at
least) that non-trivial classes couldn't be passed to varargs.

const class null_pointer {
private:
  null_pointer() {}
  null_pointer(const null_pointer &);
  inline void operator&()const;
public:
  static const null_pointer null;
  inline template<class T> operator T*()const {return 0;}
  inline template<class T, class C> operator C::T*()const {return 0;}
}null_pointer::null, &null=null_pointer::null;

inline bool
operator==(const null_pointer&, const null_pointer&) {return true;}
inline template<class T>
bool operator==(const null_pointer&, const T& t) {return 0==t;}
inline template<class T>
bool operator==(const T& t, const null_pointer&) {return t==0;}

inline
bool operator!=(const null_pointer&, const null_pointer&) {return
false;}
inline template<class T>
bool operator!=(const null_pointer&, const T& t) {return 0!=t;}
inline template<class T>
bool operator!=(const T& t, const null_pointer&) {return t!=0;}

Is this sufficient for your needs? Do you think it could be added to the
standard library?

Ted Clancy
s341282@student.uq.edu.au
BE(El&Elec)II, University of Queensland, Australia
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>>> "SC" == Steve Clamage <stephen.clamage@Eng.Sun.COM> writes:
 SC> I always thought it was a serious oversight that C lacked a 'null'
 SC> keyword. But what are the advantages of adding it to C++? For
 SC> compatibility with C code and millions of lines of existing C++ code, the
 SC> old rules about literal 0 must be kept. If 'null' were adopted and you
 SC> wrote a program using it, you could later substitute '0' for 'null'
 SC> everywhere, and I don't think it would affect the program. That is why I
 SC> didn't support any proposal to add a 'null' keyword, and I suspect many
 SC> other people felt the same way. It's a small and simple language change,
 SC> it's costs are not large, but it yields almost no benefit.

 SC> Maybe I'm wrong about this, but given the compatibility issue, I don't see
 SC> how a 'null' keyword could have the right behavior and not wind up being
 SC> merely an alternative way to spell '0'.

let's say my code originally is:

        void* foo(void* p) { .... }

        void  bar() { foo(0); ... }

adding an overloaded `foo' will break my code (at least under most compilers):

        void* foo(void* p) { ... }
        int   foo(int n) { ... }

        void  bar() { foo(0); ... }


having a null keyword will help keeping my code working:

        void* foo(void* p) { ... }
        int   foo(int n) { ... }

        void  bar() { foo(null); ... }



Or am I missing something ?

--
=====================================================================
Linh Dang                                 Nortel Technology
Member of Scientific Staff                Speech Recognition Software
linhd@nortel.ca
=====================================================================
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

linhd@no-spam-nortel.ca wrote:

> let's say my code originally is:
>
>         void* foo(void* p) { .... }
>
>         void  bar() { foo(0); ... }
>
> adding an overloaded `foo' will break my code (at least under most
> compilers):
>
>         void* foo(void* p) { ... }
>         int   foo(int n) { ... }
>
>         void  bar() { foo(0); ... }
>
> having a null keyword will help keeping my code working:
>
>         void* foo(void* p) { ... }
>         int   foo(int n) { ... }
>
>         void  bar() { foo(null); ... }
>
> Or am I missing something ?

I think the problem lies in the fact that C++ allows you to match a
pointer variable with the number zero but not with any other number.
This has always seemed like a bit of a hack to me, and I would have
preferred a null keyword from jump. However, that would have been an
additional deviation from C. And it's too late now, anyway.

--

Ciao,
Paul

(Please remove the extra "crud" from the return address,
which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Ted Clancy <s341282@student.uq.edu.au> writes:

> I think the committee would be hesitant to adopt a keyword null on
> the 'we don't want another keyword' excuse. In this case, I think
> the excuse is valid since many people have already defined their own
> 'null's. Also, semantics for the new keyword would have to be worked
> out. (Not a big task, but still a task).

4 and 3.14 aren't keyword, but they are recognized by the parser,
and true and false are keywords. I think that null should also
be known by the compiler, as 0 and (3 * 3 - 9) are. It's
consistent with the language: a litteral can be expressed with
a token.

> const class null_pointer {

A clever hack, but still a hack.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble wrote:
>
> The offending code is something like this:
>
>     if (gmtime_r(&t, &s) != 0)
>         return (-1);    // Failed
>
> It is based on the HP-UX definition of the function:
>
>     int gmtime_r(const time_t *t, struct tm *s);
>     /* Returns 0 on success */
>
> The other systems use a slightly different (POSIX) definition:
>
>     struct tm * gmtime_r(const time_t *t, struct tm *s);
>     /* Returns null on failure */
>
> So the 'if' statement above now operates backwards on POSIX systems.  Alas,
> this is not caught by the compilers.  This is because '0' is valid both as
> an integer value (zero) and as a pointer value (null).  No conforming
> compiler will complain, in spite of the fact that I'm calling a function
> with two different return types on different systems.
>
> My point is that this simple error could have been caught if C++ had a 'null'
> keyword (or reserved identifier) designed to be used for pointer comparisons.

But how often does this situation arise? How many times do you run into
functions with identical signatures except that one returns a pointer
and the other an int?

I'd hate to give up the flexibility of treating 0 as a special pointer
value just to handle this rare situation.

> Adding a 'null' keyword to C++ is a trivial thing to do, and it
> closes a semantic hole in the language.  Why not do it now, when extra
> keywords are already being added to the language?

Because as you mentioned, it would only be of use if 0 were disallowed
as a valid pointer value, which would break 99% of existing C++ code.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]