[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: [PATCH] use nullptr =?UTF-8?Q?more=3F?=
From:       Amos Jeffries <squid3 () treenet ! co ! nz>
Date:       2014-01-21 1:31:39
Message-ID: b98b6492d4c35e15f560086101359dc5 () treenet ! co ! nz
[Download RAW message or body]

On 2014-01-21 12:47, Alex Rousskov wrote:
> On 01/20/2014 02:28 PM, Amos Jeffries wrote:
>> On 2014-01-21 08:05, Alex Rousskov wrote:
>>> On 01/20/2014 08:15 AM, Kinkie wrote:
>>> 
>>>>   the attached patch is an attempt (build-tested) to rely more on
>>>> nullptr in place of NULL.
>>>> It takes from the current implementation, it is just a bit more
>>>> forceful in using nullptr if available.
>>> 
>>> Hi Kinkie,
>>> 
>>>     You forgot to mention *why* do we want to overwrite the external
>>> NULL definition? Overwriting NULL set by others will prevent folks 
>>> with
>>> broken compilers working around nullptr compatibility issues. What 
>>> will
>>> it give us in return, the ability to overwrite NULL #defined in some
>>> header we happened to #include?
>>> 
>> 
>> The only reason I know of that we might want to is that cstd* headers
>> define NULL explicitly now, whereas before C++11 it was optionally 
>> there:
> 
> 
> The above actually sounds like a reason _not_ to redefine NULL to me:
> 
>>   1/ The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>,
>> <cstdlib>, <cstring>, <ctime>, or <cwchar>, is an 
>> implementation-defined
>> C++ null pointer constant in this International Standard (18.2).
> 
> And now we are saying, "Take that International Standard! We are going
> to use what we think is the right NULL, and there is nothing you can do
> about it!"
> 

Pretty much. Although not so much as "Take that IS!" as "Take that GCC" 
since it is defined to be implementation specific. All we do with #undef 
is add risk screwing up the alignment with OS code and third-party code 
libraries which may now be depending on those compiler-specific defines.

> 
>> Strictly following the libcompat intentions we should have defined
>> nullptr_t when it was missing and replaced all uses of NULL across the
>> code. I chose not to go with that after following the standards
>> committee discussion on why they did not standardize the name "NULL".
>> They identified a minefield of backward compatibility issues with the
>> above mentioned custom definitions, all sorts of strange definitions 
>> for
>> NULL exist [eg.  #define NULL ((void*)((WIDE)(0x0C 0x0D))) was the
>> nastiest one I've seen] and people using it to define all sorts of
>> object types to an assumed OS-specific value.
> 
> I do not see how redefining NULL (on top of the above mess) would
> necessarily be better than leaving it alone. Are we trying to fix cases
> where different 3rd-party headers #define NULL differently?

Exactly.

It exists in its current form to fix systems where it is completely 
omitted. Changing an existing definition is risky.

> 
> For the record, I am not objecting to this change. It would be great to
> understand why it is being done, but if others are sure it is needed,
> you do not need to convince me.

I don't think any change here is needed. The existing hack (and it is 
just a hack) was a good idea at the time, and still is for all the GCC 
4.0-4.5 compilers and old systems not defining it at all. But it is 
becoming increasingly irrelevant and when we someday switch to requiring 
a C++11 compiler NULL can be erased completely.

Amos
[prev in list] [next in list] [prev in thread] [next in thread]