[PATCH] Fallback to operator new for MSVC compatibility

[Richard Smith]

What does MSVC think about:

void *operator new(unsigned int size, arbitrary_t);
void operator delete[](unsigned int size, arbitrary_t) = delete;
struct S { S(); };
S *p = new (arbitrary) S[5];

? Will it call the (deleted) operator delete[] even though it picked a
non-array operator new?

What if there is an array new but no array delete?

On Tue, May 28, 2013 at 12:26 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> MSVC has a "neat trick" where it automatically falls back onto
> operator new when a placement operator new[] is called for which there
> is no valid declaration.  Eg)
>
> struct arbitrary_t {} arbitrary;
> void *operator new(unsigned int size, arbitrary_t);
>
> void f() {
>   int *p = new(arbitrary) int[4];
>   int *p2 = new(arbitrary) int;
> }
>
> MSVC will emit code to call operator new even though operator new[]
> does not exist.
> ...
> push 16 ; 00000010H
> call ??2 at YAPAXIUarbitrary_t@@@Z ; operator new
> ...
> push 4
> call ??2 at YAPAXIUarbitrary_t@@@Z ; operator new
> ...
>
> This patch emulates the MSVC behavior when compiling in
> ms-compatibility mode and tests both the semantic requirements as well
> as the codegen requirements.  It addresses PR13164, which points out
> that this is holding back usage for the WDK because it does not
> implement the array version of nothrow'ing new.
>
> ~Aaron
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130528/1d26ebbb/attachment.html>