Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: question about nullptr
Date: Wed, 10 Jul 2024 14:27:45 +0100
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <87ttgxnzqm.fsf@bsb.me.uk>
References: <v6bavg$3pu5i$1@dont-email.me>
	<90c2181ae4c7aac8f17f076093923d5b357c43aa@i2pn2.org>
	<v6bt15$3svoi$1@dont-email.me> <v6iik7$1948o$1@dont-email.me>
	<v6iklk$19cv8$1@dont-email.me> <v6inai$19q6r$1@dont-email.me>
	<v6insm$19uag$1@dont-email.me> <874j8yswha.fsf@bsb.me.uk>
	<v6k6a3$1gsq2$3@dont-email.me> <v6k6ha$1gsq2$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Jul 2024 15:27:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4de7691f4ab8416481d0de19b6a8d938";
	logging-data="2035642"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1935t3peQfZdQb0lvZ2B5vkNeLlJW9Br9k="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:eDzkjSRUSO4xkKzS2Z2vY/uI5B8=
	sha1:F5hUFZhPEyB49GmAx4CLmFqXvdY=
X-BSB-Auth: 1.f8768042f5c9ed4b5774.20240710142745BST.87ttgxnzqm.fsf@bsb.me.uk
Bytes: 3808

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 7/9/2024 1:24 PM, Chris M. Thomasson wrote:
>> On 7/9/2024 3:14 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>
>>>> p = nullptr;
>>>
>>> (p having been declared void *)
>>>
>>>> (0 == p == nullptr == NULL == 0) == true ?
>>>>
>>>> Am I missing something here? If so, here is a preemptive: Shit!
>>>
>>> You are missing that 0 == p == nullptr == NULL == 0 does not mean what
>>> you want!  It means
>>>
>>>   (((0 == p) == nullptr) == NULL) == 0
>>>
>>> and that is a constraint violation.
>>>
>>> Why?  Well 0 == p has value 1 and is of type int and equality
>>> comparisons between int and nullptr_t values (of which there is only
>>> one) are not permitted.  Catching this sort of thing is one of the
>>> benefits of nullptr and its associated type nullptr_t.  It means that
>>> while
>>>
>>> #define nullptr ((void *)0)
>>>
>>> can help to get C23 code to compile with a pre-C23 compiler, it might
>>> result in some C23 constraint violations going undetected.
>>>
>>> Anyway, that aside, I know what you meant.  To clarify, all of the
>>> following have the value 1:
>>>
>>>    0 == p
>>>    p == nullptr
>>>    nullptr == NULL
>>>    NULL == 0
>>>    0 == nullptr
>>>    !p
>>>
>>> Note that 0 == nullptr /is/ allowed even though 0 has type int.  That is
>>> because 0 is also a null pointer constant, and the rules for == and !=
>>> specifically allow it.
>>>
>> It was a bit of pseudo code.

It looked like C!

>> Here is a program:
>> __________________________
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main()
>> {
>>      void* p = 0;
>>      if ((p == NULL) && (! p))
>>      {
>>          printf("Good!\n");
>>      }
>>      else
>>      {
>>          printf("Strange? Humm...\n");
>>      }
>>      return 0;
>> }
>> __________________________
>> Good shall be printed even with the following condition right?
>> __________________________
>> if ((p == NULL) && (! p) && (p == nullptr))
>> {
>>     printf("Good!\n");
>> }
>> __________________________
>> Any better Ben?
>
> To be more precise, printf shall be called if p is 0, NULL or
> nullptr... They are all the same, in a sense, right?

In a sense, yes.  If you want to know the senses in which they are not
all the same, ask some more (or read the C23 draft PDF).

-- 
Ben.