Am Freitag, den 30.04.2021, 10:12 -0400 schrieb will wray via Liaison:
> 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 security problems related to VLAs on the stack
can be avoided by compilers doing stack probing.

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

And also compared to larger fixed sized arrays
on the stack.

Best,
Martin

> > On Fri, 30 Apr 2021 at 11:47, Jₑₙₛ Gustedt <jens.gustedt_at_inria.fr>
> > 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_inria.fr
> > >
> > > 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ₑₙₛ
> >
> > _______________________________________________
> > 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/0529.php