Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about nullptr
Date: Sun, 7 Jul 2024 12:53:17 -0700
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <v6erne$f608$3@dont-email.me>
References: <v6bavg$3pu5i$1@dont-email.me> <20240706054641.175@kylheku.com>
 <v6bfi1$3qn4u$1@dont-email.me> <l9ciO.7$cr5e.2@fx05.iad>
 <v6c942$3ui41$1@dont-email.me> <v6crt3$1gpa$2@dont-email.me>
 <87frsmsznj.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 07 Jul 2024 21:53:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0ecdb18ed35c2abf38d5c9c78345642e";
	logging-data="497672"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/oiRymYqLJfkFAHM9PtIErLvulcHsJj0U="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ubydp5QHqVmnctEmOcxgdBlxAvU=
In-Reply-To: <87frsmsznj.fsf@nosuchdomain.example.com>
Content-Language: en-US
Bytes: 2921

On 7/6/2024 7:29 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 7/6/24 4:23 PM, Chris M. Thomasson wrote:
>>> On 7/6/2024 7:04 AM, Scott Lurndal wrote:
>> ...
>>>> Whereas I spent 6 years programming on an architecture[*] where a
>>>> null pointer was represented in hardware by the value 0xc0eeeeee.  I
>>>> always
>>>> use the NULL macro in both C and C++ code.
>>>
>>> Where:
>>>
>>> void* x = 0;
>>>
>>> Should be x = 0xc0eeeeee, right?
>>
>> No, 0 is a null pointer constant. The C standard requires that when a
>> null pointer constant is converted to a pointer value, it must be
>> converted to a null pointer of that type. The result will be that the
>> representation of 'x' after such an assignment would be 0xc0eeeeee.
>>
>> Whether or not an integer value of 0xc0eeeeee can be converted to a
>> pointer type, and what that pointer's value would be after the
>> conversion is up to the implementation.
>>
>> Note that even after x acquires that representation, it's still required
>> to compare equal to 0. For the purposes of the comparison, the null
>> pointer constant gets converted to a null pointer of the appropriate
>> type. All null pointers, regardless of representation (the C standard
>> allows there to be multiple ways of representing null pointers) must
>> compare equal.
> 
> Furthermore, `void* x = 0xc0eeeeee;` is a constraint violation.  There
> is no implicit conversion from integers to pointers other than the
> special case of a null pointer constant, which 0xc0eeeeee is not.
> 

void* x = (void*)(0xc0eeeeee); // aka NULL
void* y = 0; // NULL, right?

x == y is true...

Still shitty?