Re: [PATCH] Define NULL as __null in C++ mode when using GCC or Clang.

[Rich Felker <dalias@libc.org>]

On Wed, Jul 10, 2019 at 11:11:55PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2019-07-10 16:48:12 -0400]:
> > On Wed, Jul 10, 2019 at 01:35:35PM -0400, James Y Knight wrote:
> > > My leaning would kinda be to use
> > > > nullptr in recent C++ versions and retain 0L for old ones if nullptr
> > > > is a valid definition in new C++ versions, but I still wonder if
> > > > having use of NULL "break maximally" isn't a better behavior with
> > > > respect to ending its use...
> > > >
> > > 
> > > #define NULL nullptr is standards-valid in c++11 and later, but would be an
> > > unfortunate choice to make. Both in terms of breaking working code (code
> > > which is making unportable assumptions, granted), but also in terms of
> > > breaking ABIs on valid code: changing the type from long to
> > > decltype(nullptr) changes mangling, etc.
> > 
> > Could you clarify how it "breaks ABI"? NULL is not a type but a macro
> > expanding to an expression. Does its type somehow leak into mangled
> > symbol names via templates or something? If so, this is a complication
> > to any proposed change of the type.
> 
> void f(int);
> void f(long);
> void f(void*);
> ....
> f(NULL); // if NULL is 0 vs 0L then the int vs long version is called.
> 
> so the dispatch (and called symbol) depends on the definition of NULL
> 
> __null behaves like 0L, nullptr would dispatch to the void* version.

I see. I don't see this as ABI breakage, but rather as a change in the
behavior produced by non-portable code. But I wonder if it's also
possible to see ABI breakage from a change.

> i think modern c++ code should use nullptr in the code.
> 
> definition of NULL should be imo kept as 0L (that's what
> you would get on older unix systems or on openbsd anyway)
> apparently some ppl prefer __null.

Do you know if OpenBSD has a reason they do it this way?

Rich