[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190710204812.GV1506@brightrain.aerifal.cx>
Date: Wed, 10 Jul 2019 16:48:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Define NULL as __null in C++ mode when using GCC
or Clang.
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.
Rich
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.
