C++: variable length arrays and operator new[]

C++: variable length arrays and operator new[]

[Florian Weimer]

G++ currently accepts the following code:

char *
alloc(unsigned a, unsigned b)
{
  typedef char array[a];
  return &**(new array[b]);
}

Is this intentional?  The equivalent "new char[a][b]" is rejected (as
required by the C++ standard).

Re: C++: variable length arrays and operator new[]

[Ian Lance Taylor]

Florian Weimer <fw@deneb.enyo.de> writes:

> G++ currently accepts the following code:
>
> char *
> alloc(unsigned a, unsigned b)
> {
>   typedef char array[a];
>   return &**(new array[b]);
> }
>
> Is this intentional?  The equivalent "new char[a][b]" is rejected (as
> required by the C++ standard).

Is there any reason that g++ should reject your sample program?

Because of the existence of operator new[], "new char[a][b]" quite a bit
harder to understand than your code is.

Ian

Re: C++: variable length arrays and operator new[]

[Gabriel Dos Reis]

On Mon, Sep 21, 2009 at 4:56 PM, Ian Lance Taylor <iant@google.com> wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> G++ currently accepts the following code:
>>
>> char *
>> alloc(unsigned a, unsigned b)
>> {
>>   typedef char array[a];
>>   return &**(new array[b]);
>> }
>>
>> Is this intentional?  The equivalent "new char[a][b]" is rejected (as
>> required by the C++ standard).
>
> Is there any reason that g++ should reject your sample program?

Yes: there is no obvious reason for gratuitous incompatibility in semantics.

>
> Because of the existence of operator new[], "new char[a][b]" quite a bit
> harder to understand than your code is.

But, new char[4][3] is OK.

FWIW, I do really find the VMT version far harder to understand.

>
> Ian
>

Re: C++: variable length arrays and operator new[]

[Florian Weimer]

* Gabriel Dos Reis:

>>> Is this intentional?  The equivalent "new char[a][b]" is rejected (as
>>> required by the C++ standard).
>>
>> Is there any reason that g++ should reject your sample program?
>
> Yes: there is no obvious reason for gratuitous incompatibility in
> semantics.

That, and it requires full saturating multiplication support at
run-time if we want to fix PR19351 in the most straightforward way (by
passing size_t(-1) to the underlying allocator function in case of
overflow).