Sujet : Re: question about nullptr
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 07. Jul 2024, 00:31:44
Autres entêtes
Organisation : None to speak of
Message-ID : <87wmlyt7vj.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5
User-Agent : Gnus/5.13 (Gnus v5.13)
bart <
bc@freeuk.com> writes:
On 06/07/2024 15:04, 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.
>
You can ignore that requirement and just use all-bits-zero (in memory,
not just in C source code). After all, the only thing you might want
hardware support for is trapping a dereference of a NULL value.
You write this in response to someone saying they've used a system
where a null pointer is *not* all-bits-zero.
The vast majority of systems do represent a null pointer as
all-bits-zero, and you can usually get away with assuming that.
There are even some cases where it might be worthwhile, for example
if you need to memset chunks of memory that contain pointers and
aren't concerned about 100% portability (or if you're using your
own langauge).
Or you can use the language in a way that works correctly regardless
of now null pointers are represented. That's what I do.
[...]
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */