Thanks, Jens G., for that nice summary description
of variably-modified types and their usage.

> If C++ wouldn't allow the declaration of VLA, fine,
> maybe C could even remove that possibility.

What is needed is a safer way to manage stack-
allocated data, in both C and in C++.
Only then should VLA be deprecated.

The stack allocation that VLA provides
is preferable to the alternative; alloca

> On Fri, 30 Apr 2021 at 11:47, Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
> wrote:

On Fri, Apr 30, 2021 at 9:54 AM Jₑₙₛ Gustedt via Liaison <
liaison_at_[hidden]> wrote:

> Ville,
>
> on Fri, 30 Apr 2021 11:59:40 +0300 you (Ville Voutilainen
> <ville.voutilainen_at_[hidden]>) wrote:
>
> > On Fri, 30 Apr 2021 at 11:47, Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
> > wrote:
> > > My personal experience when talking to people from the C++ community
> > > is that often there is a lack of such understanding. For example, to
> > > know that VLA and VM types are different things, that VM types as
> > > function interfaces don't have the disadvantages that have automatic
> > > VLA if defined on the stack, and that VM types can easily be
> > > dynamically allocated with no fuzz.
> > >
> > > Discussion about VM types (or VLA because people don't know the
> > > difference) quickly become hostile. It seems that historically the
> > > subject is quite overloaded. I would be cool if we could overcome
> > > that social difficulty.
> >
> > I would kindly suggest that we start by you explaining by what you
> > mean by "VM type". :)
>
> sure!
>
> In the C standard "VM type" stands for "variably modified type" and
> comprises VLA and pointers to VLA.
>
> In contrast to VLA themselves, pointers to VLA need only an amount of
> storage that is fixed a compile time, so no stack overflow or other
> nasty things like that can happen.
>
> They are ABI compatible with usual pointers to arrays. That is
> particularly interesting for function parameters of VLA type that decay
> to such pointers, anyhow. Here an extended syntax (compared to C++)
> allows to specify dynamic bounds that are evaluated in the scope of
> defined function, and that allows (with some restrictions) the transfer
> and verification of such bounds from the caller to the callee.
>
> Another interesting application are dynamic allocations as Martin had
> shown in one of the initial posts in this thread
>
> double (*x)[M] = malloc(sizeof(double[N][M]));
> ...
> x[i][j] = 0.;
> ...
> free(x);
>
> Here, `x` can be used as a 2D matrix where the compiler can do all
> index calculations without problems.
>
> So where VLA themselves can be questioned for their inherent danger
> for stack overflow, pointers to VLA are safe and provide good
> opportunities for bound checking and efficient interfaces.
>
> For an increased compatibility between C and C++, adding pointers to
> VLA to C++ would be a winner, because that would make a lot of
> numerical code portable between the two languages.
>
> If C++ wouldn't allow the declaration of VLA, fine, maybe C could even
> remove that possibility. I personally wouldn't mind much. (In C we
> would need better integer constant expressions for the array bounds
> before that, though.)
>
>
> Thanks
> Jₑₙₛ
>
> --
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: ::::::::::::::: office Strasbourg : +33 368854536 ::
> :: :::::::::::::::::::::: gsm France : +33 651400183 ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/04/0528.php
>