Path: ...!weretis.net!feeder9.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: question about nullptr
Date: Tue, 9 Jul 2024 02:45:19 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <20240708193402.610@kylheku.com>
References: <v6bavg$3pu5i$1@dont-email.me> <20240706054641.175@kylheku.com>
 <v6bfi1$3qn4u$1@dont-email.me> <l9ciO.7$cr5e.2@fx05.iad>
 <877cdyuq0f.fsf@bsb.me.uk> <2ckiO.19403$7Ej.4487@fx46.iad>
 <87plrpt4du.fsf@bsb.me.uk> <9bCiO.7108$sXW9.3805@fx41.iad>
 <87jzhwu5v9.fsf@bsb.me.uk> <v6gv4f$tp07$1@dont-email.me>
Injection-Date: Tue, 09 Jul 2024 04:45:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="eb6f9df33a8cab964bf8a3b5b8508662";
	logging-data="1297100"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ed3X4ahfMD9b6aljDAOYkZpp9tf+fwFE="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:wCS+rV7BEz5YtKFj6tTvVbizW+0=
Bytes: 3391

On 2024-07-08, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 7/7/24 19:42, Ben Bacarisse wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
> ...
>>> I.e. it can either be a null pointer or the value zero
>>> depending on context, which makes it ambiguous to the casual
>>> reader. Particularly when reading code that someone
>>> else has written. NULL makes the programmers intent crystal
>>> clear.
>>
>> That's a rather niche readership -- one that might consider
>>
>> char *p = 0;
>>
>> unclear. Do you want such people reading your C code with a view to
>> working on it?
>
>
> The problem is not "char p=0;". If you're sure what type p has, there's
> no problem. The problem comes with code like "p=0", where "p=NULL" would
> serve to remind you that p should be a pointer, while "p=nullptr"
> guarantees a diagnostic if p is not a pointer.

The programming world has moved away from tying syntax to concrete
implementation though. For every time you worry in p = 0,
p is floating, integer or pointer, a thousand coders somewhere
are doing writing obj.foo(), where the type of obj can be one of
half a dozen different things at run-time.

p = 0 is nicely generic: "make p null, whatever it is".

A pointer "responds" to this "method" by becoming null.

And anyway, if the expression is p + 3 instead, what tells you then
whether it's an integer, float or pointer. Should we have a 
ptrplus keyword for displacing pointers?

Ancient C, or pre-C, had separate operators for floating-point,
prefixed with a hash: #+, #-, #*, ...

> I have fixed bugs which
> would have been caught a lot earlier if nullptr had existed, and had
> been the only permitted kind of null pointer constant.

All the ones I remember were about 0 being used as a variadic
pointer argument, without a cast. I can't think of anywhere else
it would be a problem.

nullptr being the only null pointer constant would prevent that
where the type is void * or char *, (or where pointers of all types all
have the same representation).


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca