Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.c Subject: Re: question about nullptr Date: Thu, 11 Jul 2024 00:25:42 +0100 Organization: A noiseless patient Spider Lines: 62 Message-ID: <87cynkommh.fsf@bsb.me.uk> 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> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Thu, 11 Jul 2024 01:25:43 +0200 (CEST) Injection-Info: dont-email.me; posting-host="8f0c59e317bc680ad3ae1d9bc8fc08f2"; logging-data="2212801"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/RApZWlKUSk+nipwa7DSyBdl/ZqSoW9+M=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:f2NFK2acQtLrUKZxefMCQw0+XoU= sha1:L/LaFDXx8u/Pvn4fTbcwMcrY73o= X-BSB-Auth: 1.1963dcffc3ae463c5e03.20240711002542BST.87cynkommh.fsf@bsb.me.uk Bytes: 4026 Janis Papanagnou writes: > On 09.07.2024 00:55, Ben Bacarisse wrote: >> Janis Papanagnou writes: >> >>> On 08.07.2024 18:23, Ben Bacarisse wrote: >>>> Janis Papanagnou writes: >>>> >>>>> On 08.07.2024 12:18, Ben Bacarisse wrote: >>>>>> Janis Papanagnou writes: >>>>>>> >>>>>>> What's superfluous to one is useful for others (e.g. for grep'ing >>>>>>> occurrences of a null-pointer value in source codes); >>>>>> >>>>>> This is been suggested twice now but I'm struggling to see why that is >>>>>> useful. I can see management wanting one to find all uses of a null >>>>>> pointer constant to check that they have all been replaced by the >>>>>> "safer" nullptr, but what's the value in searching for nullptr? >>>>> >>>>> Bug-tracking. >>>> >>>> Can you say more? >>> >>> Frankly, no. [...] >> >> OK. > > So the text you snipped from my reply did not trigger any insight? I didn't read it. You said you could not say more so I assumed what you'd written was not saying more but something else like repeating what you'd already said. > Another, last try... > 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.) 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. 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? -- Ben.