[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMbhsRQ0p-e5DjGrUvPZZmepdeAHfvGQKmMWMiBs+a4BPMA14Q@mail.gmail.com>
Date: Thu, 23 Dec 2021 11:13:01 -0800
From: Colin Cross <ccross@...gle.com>
To: musl@...ts.openwall.com
Cc: Ismael Luceno <ismael@...ev.co.uk>
Subject: Re: [PATCH] Define NULL as nullptr when used in C++
On Sun, Aug 15, 2021 at 05:51:57PM +0200, Ismael Luceno wrote:
> This should be safer for casting and more compatible with existing code
> bases that wrongly assume it must be defined as a pointer.
This seems to meet the C++ spec for NULL [1], but I noticed some
compatibility issues with code that was previously compiling with
glibc.
I've found multiple places that used reinterpret_cast<int*>(NULL),
which now fail with:
error: reinterpret_cast from 'nullptr_t' to 'int *' is not allowed
According to [2] those should technically be static_cast and not
reinterpret_cast.
I've also seen failures with returning NULL from a function with a
jlong return type:
error: cannot initialize return object of type 'jlong' (aka 'long')
with an rvalue of type 'nullptr_t'
glibc uses __null if __GNUG__ is set, ((void*)0) for __cplusplus, or 0 for C.
This also meets the C++ spec for NULL [1], but is an improvement over
the previous 0L because it can be correctly interpreted as a NULL
sentinel value by Clang's -Wsentinel warning.
Ismael, can you give an example of the code that assumes NULL is a
pointer? Does it work with __null (assuming you're using a compiler
that has GNU extensions like __null)?
In any case, I'll fix the technically incorrect code I have access to
so that it works with nullptr.
[1] https://en.cppreference.com/w/cpp/types/NULL
[2] https://en.cppreference.com/w/cpp/language/reinterpret_cast
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
