Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch 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: <20240706054641.175@kylheku.com> <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> <878qyctcdt.fsf@bsb.me.uk> <8734ojua2s.fsf@bsb.me.uk> <87sewjsdc5.fsf@bsb.me.uk> <87cynkommh.fsf@bsb.me.uk> 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 writes: > On 11.07.2024 01:25, Ben Bacarisse wrote: > >> Janis Papanagnou 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.