(11) RFR (S) JDK-8196880: VS2017 Addition of Global Delete Operator with Size Parameter Conflicts with Arena's Chunk Provided One

[coleen.phillimore at oracle.com]

On 2/16/18 11:28 AM, Lois Foltan wrote:
> On 2/16/2018 8:43 AM, coleen.phillimore at oracle.com wrote:
>
>>
>> This is odd but seems ok.
>>
>> If you make the dummy operator delete private, does it still 
>> compile?   If it is actually used, will it get a linktime error 
>> rather than a compile time error?
> Hi Coleen,
> Thanks for the review.  Yes, making the operator delete private does 
> work and I have updated the webrev.  If it is actually used it will 
> get a linktime error.
>
> Updated webrev at: 
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8196880.1/webrev/

I like this.   See what Kim says, I guess.  If someone tries to call it 
they should get a compile time error first.   I believe...

thanks!
Coleen

> Lois
>
>>
>> thanks,
>> Coleen
>>
>> On 2/14/18 8:48 AM, Lois Foltan wrote:
>>> Please review this change in VS2017 to the delete operator due to 
>>> C++14 standard conformance.  From 
>>> https://msdn.microsoft.com/en-us/library/mt723604.aspx
>>>
>>> The function|void operator delete(void *, size_t)|was a placement 
>>> delete operator corresponding to the placement new function "void * 
>>> operator new(size_t, size_t)" in C++11. With C++14 sized 
>>> deallocation, this delete function is now a/usual deallocation 
>>> function/(global delete operator). The standard requires that if the 
>>> use of a placement new looks up a corresponding delete function and 
>>> finds a usual deallocation function, the program is ill-formed.
>>>
>>> Thank you to Kim Barrett for proposing the fix below.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8196880/webrev/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8196880
>>>
>>> Testing complete (hs-tier1-3, jdk-tier1-3)
>>>
>>> Thanks,
>>> Lois
>>>
>>>
>>
>