[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190710211154.GL21055@port70.net>
Date: Wed, 10 Jul 2019 23:11:55 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Define NULL as __null in C++ mode when using GCC
or Clang.
* Rich Felker <dalias@...c.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 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.
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.
