Am Freitag, den 30.04.2021, 11:32 -0400 schrieb Aaron Ballman:
> On Fri, Apr 30, 2021 at 10:32 AM Uecker, Martin via Liaison
> <liaison_at_[hidden]> wrote:
> > 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.
>
> Not a disagreement so much as a reality check -- stack probing has
> overhead costs to it, which makes for a natural tension between
> "faster and more insecure" and "slower but more secure". So yes,
> stack probing *can* reduce the security risk, but only if the stack
> probing is actually performed. So long as that decision is left in
> users (or implementations) hands, the security of using VLAs will
> remain questionable (to me, at least).

Stack probing would also be relevant in other cases, e.g. when
you have a regular array on the stack which is bigger than a
page or other objects in a single stack frame which are together
bigger than a page. If you do not want the cost of stack
probing (which can be optimized away so is not that expensive)
then you need to avoid all this and not just VLAs. (And of
course, compilers could just have an option to place the VLAs
on the heap.)


Best,
Martin


>
> ~Aaron
>
> > > 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]om>) 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
> > _______________________________________________
> > 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/0530.php