Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: question about nullptr
Date: Wed, 17 Jul 2024 09:26:26 -0700
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <86h6co56j1.fsf@linuxsc.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> <20240708001722.280@kylheku.com> <v6gab6$qdd2$1@dont-email.me> <878qyctcdt.fsf@bsb.me.uk> <v6gf23$r5pf$1@dont-email.me> <8734ojua2s.fsf@bsb.me.uk> <v6h9su$vkip$1@dont-email.me> <87sewjsdc5.fsf@bsb.me.uk> <v6m9bn$1vbsi$1@dont-email.me> <87cynkommh.fsf@bsb.me.uk> <v6r6c7$3122q$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 17 Jul 2024 18:26:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3670327c1da6279f75fc57abea437cce";
	logging-data="2024235"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18wPITjLpFOEdJ+8CCw+g69bZeKXRdKSVY="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:88nsVo9+cUC332QYqWWo0mz3iA4=
	sha1:xhntY6sCQjpVol3qM2E6IuvJvRg=
Bytes: 6671

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 11.07.2024 01:25, Ben Bacarisse wrote:
>
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> [...]
>>> Compare it to 'enum' constants.  When I code or debug I want to track
>>> (search and find) them by name not by integer number.
>>> Similar with the 'enum' bool type we introduced (when there was not
>>> yet a bool type existing in C or C++) with literal constants 'true'
>>> and 'false'.  (Only two values, but still as important.)
>>> Similar with the dedicated pointer value 0 (these days we used the
>>> literal 'null').  (Only one value, still useful for tracking eq/ne
>>> comparisons and initializations.)

Neither of these analogies illuminates the question, which is How
is searching for a null pointer value useful.  The enum analogy
suffers both from being much more type specific and from being a
more distinguished value, unlike NULL which applies to all pointer
types, and almost certainly is more broadly used than any of the
named constants defined in an 'enum' type.  The bool analogy is a
more faithful analogy but presents the same question:  how is
searching for a constant like 'true' or 'false' useful?  We might
want to know how a particular variable acquired a particular value
('true', say), but for that question it seems much more fruitful to
search for the variable, or where a particular function is called,
than it does for search for 'true' or 'false'.  Also boolean values
can be the result of a C operator such as '<' or '&&', so searching
for 'true' or 'false' need not turn up the expression being sought.
In fact in the case of booleans I think it is much more likely that
a value being assigned comes from a C operator than it does from a
boolean constant.

>> Yes, you've said that before.  You want to search for nullptr.  I
>> can't think of how that might help find a real bug, if that's what
>> you mean by bug-tracking.
>>
>> I was hoping for a story...  "Once I had this bug where... and if
>> I'd been using nullptr I'd have found it a day earlier" kind of
>> thing.  I'd found a lot of bugs over the years, but I don't recall
>> any that would have been easier to find had I been able to search
>> for nullptr.
>>
>> I was looking for real-world insight here.  Obviously one could
>> make up a bug where p = nullptr; was written where, say, p = null -
>> ptr;  was intended, but that's not what I mean.
>>
>> Without such an example, your argument seems to be overly generic.
>
> That's why I had problems to "explain" the reasons to you;  because
> it's so universal a property, so obvious (as I said), that I don't
> know what else I could say.  (Likewise with "real-word examples".)
> What example could I give that explains that if you're looking for
> specific dedicated semantical values it's easier to look them up
> by [semantical] name than by a [ambiguous] number.  Yes this speeds
> up detection of errors when doing code inspections (for bugs or as
> QA measure), and yes, this was helpful for program development and
> bug detection in [my professional and private] practice.

Ben explains exactly what he is looking for -- a story -- and you
respond by not giving him one.  What's up with that?  Your comment
that something is obvious, followed by an unanswered rhetorical
question, is totally lame.  Ben is asking (I infer) precisely
because such a story or example is not obvious to him.  I can say
for sure that it is not obvious to me.

>> Would you welcome the introduction of the keyword unity -- with the
>> value 1 and type int -- into C because one could then search for it?
>
> No.  (Please don't start to be ridiculous. - Or did you really miss
> the point? - No offense intended.)

I think it is you who is missing the point.  Ben's comment is not a
suggestion but a question.  Moreover as I read the question it is a
sincere effort to gain some insight into what you think and why.
And in response rather than try to answer the question in any helpful
way, instead you ridicule him.  This response does nothing to answer
his question, nor does it give the impression that you are really
listening.  You might want to think about that if you want your
remarks here to be taken seriously.

I want to say something about the nature of newsgroup dialog.
Recently Ben and I had a lengthy exchange where we tried to sort
out our mutual misunderstandings of the other's reading of a
particular passage in the C standard.  It wasn't easy to get to
the key underlying assumptions that prompted our respective
viewpoints.  I know from first-hand experience that Ben is a
smart and thoughtful guy, but despite that we formed radically
different views about something that seemed "obvious" to both
of us.  (I'm not sure how obvious the views were, in either
Ben's case or my own, but I do know it took a lot of explanation
on both sides to get to the point where we understood each
other, which is an indicator that we thought of our own views as
obvious.)  I think the lesson here is that in many cases it is
the most "obvious" thoughts that are most in need of explanation.