«

On Wednesday, September 5, 2012 9:59:24 AM UTC+3, jacob navia wrote:
> Le 05/09/12 00:13, Ian Collins a écrit :
>
> > Your example proves the point: you test the malloc, but assume the VLA.
>
> int fn(void)
> {
> int i;
> }
>
> You do not test for "int i;"
>
> We should ban then all stack allocation?
>
> What are you saying actually? I do not understand what you want.

The VLA is actually non-standard alloca() standardized behind array
declaration syntax. Using alloca() for up to few hundred bytes was
generally fine and improved performance. Nothing revolutionary there.

Bad usage of alloca() resulted with some legendary stories about
most memorable stack overflow fun. Similar things will happen with
those VLAs.

So Ian is worried. Jacob maybe uses it nicely. Next noob in team
however breaks it and then it is harder to track down than alloca().
VLA is not that easy to find with text search unlike alloca().

Ian Collins <ian-> writes:

> On 09/ 5/12 06:59 PM, jacob navia wrote:
>> Le 05/09/12 00:13, Ian Collins a écrit :
>>> Your example proves the point: you test the malloc, but assume the VLA.
>>
>> int fn(void)
>> {
>> int i;
>> }
>>
>> You do not test for "int i;"
>>
>> We should ban then all stack allocation?
>>
>> What are you saying actually? I do not understand what you want.
>
> VLAs are a vulnerability waiting to happen. Not as bad as gets, but
> dodgy none the less.

I don't understand this. I need more information. My guess is that you
are referring to environments that don't check stack accesses, but
that's not really the fault of the language feature.

There's a point I've been meaning to make, and I might as well inject
here since it is at least tangentially related to the above. On systems
that check stack access I don't see anything logically different between
using a VLA and doing the very common

if ((p = malloc(size)) == NULL) {
fprintf(stderr, "Eek! Out or memory.\n");
exit(EXIT_FAILURE):
}

Sure, you might have less stack available, and the error message you get
from a stack overflow might be more cryptic, but VLAs are criticised on
other grounds entirely.

<snip>
--
Ben.

Ian Collins <ian-> writes:

> On 09/ 6/12 02:57 AM, Malcolm McLean wrote:
<snip>
>> What he is saying is that you test whether the call to malloc() has
>> succeeded, but simply assume that the vla allocation has succeeded.
>> But it's not a very good point. If you set a cap on the amount that
>> can be allocated on the stack, you can know that the stack won't be
>> breached, assuming non-recursive functions. That does raise the
>> issue, however, why use a vla at all, since you might as well
>> allocate the maximum as a fixed buffer? Arguably a vla provides
>> better documentation.
>
> It may provides better documentation, but it precludes static analysis
> of stack usage.

Sorry, I'm repeating myself! How does a VLA preclude static analysis of
stack usage?

--
Ben.

On 2012-09-06, Öö Tiib <> wrote:
> On Wednesday, September 5, 2012 9:59:24 AM UTC+3, jacob navia wrote:
>> Le 05/09/12 00:13, Ian Collins a écrit :
>>
>> > Your example proves the point: you test the malloc, but assume the VLA.
>>
>> int fn(void)
>> {
>> int i;
>> }
>>
>> You do not test for "int i;"
>>
>> We should ban then all stack allocation?
>>
>> What are you saying actually? I do not understand what you want.
>
> The VLA is actually non-standard alloca() standardized behind array
> declaration syntax. Using alloca() for up to few hundred bytes was
> generally fine and improved performance. Nothing revolutionary there.
>
> Bad usage of alloca() resulted with some legendary stories about
> most memorable stack overflow fun. Similar things will happen with
> those VLAs.

Last I looked, the dynamic linker in glibc (i.e. on most Linux installations)
uses alloca for allocating tables. The allocation is proportional to the number
of symbols to be resolved or something like that. Found this the hard way when
I was trying to reduce the thread stack sizes in a large application with many
threads. The main thread wanted more than a megabyte, and crashed even before
main was invoked.

On Sep 6, 8:12*am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Ian Collins <ian-n...@hotmail.com> writes:
> > On 09/ 5/12 06:59 PM, jacob navia wrote:
> >> Le 05/09/12 00:13, Ian Collins a écrit :
> >>> Your example proves the point: you test the malloc, but assume the VLA.
>
> >> int fn(void)
> >> {
> >> * * * *int i;
> >> }
>
> >> You do not test for "int i;"
>
> >> We should ban then all stack allocation?
>
> >> What are you saying actually? I do not understand what you want.
>
> > VLAs are a vulnerability waiting to happen. *Not as bad as gets, but
> > dodgy none the less.
>
> I don't understand this. *I need more information. *My guess is that you
> are referring to environments that don't check stack accesses, but
> that's not really the fault of the language feature.
>
> There's a point I've been meaning to make, and I might as well inject
> here since it is at least tangentially related to the above. *On systems
> that check stack access I don't see anything logically different between
> using a VLA and doing the very common
>
> * if ((p = malloc(size)) == NULL) {
> * * * *fprintf(stderr, "Eek! *Out or memory.\n");
> * * * *exit(EXIT_FAILURE):
> * }
>
> Sure, you might have less stack available, and the error message you get
> from a stack overflow might be more cryptic, but VLAs are criticised on
> other grounds entirely.

This is probably before my time, but why wasn't a NULL returning
'alloca' equivalent included in the standard?

ImpalerCore <> writes:
<snip>
> This is probably before my time, but why wasn't a NULL returning
> 'alloca' equivalent included in the standard?

From "Rationale for International Standard - Programming Languages - C"
(Revision 5.10, April-2003):

"Some implementations provide a function, often called alloca, which
allocates the requested object from automatic storage; and the object
is automatically freed when the calling function exits. Such a
function is not efficiently implementable in a variety of
environments, so it was not adopted in the Standard."

--
Ben.

On 09/ 7/12 12:16 AM, Ben Bacarisse wrote:
> Ian Collins<ian-> writes:
>
>> On 09/ 6/12 02:57 AM, Malcolm McLean wrote:
> <snip>
>>> What he is saying is that you test whether the call to malloc() has
>>> succeeded, but simply assume that the vla allocation has succeeded.
>>> But it's not a very good point. If you set a cap on the amount that
>>> can be allocated on the stack, you can know that the stack won't be
>>> breached, assuming non-recursive functions. That does raise the
>>> issue, however, why use a vla at all, since you might as well
>>> allocate the maximum as a fixed buffer? Arguably a vla provides
>>> better documentation.
>>
>> It may provides better documentation, but it precludes static analysis
>> of stack usage.
>
> Sorry, I'm repeating myself! How does a VLA preclude static analysis of
> stack usage?

Because you don't know until run time how long it will be. If you did,
you wouldn't need a variable length.

--
Ian Collins

On 09/ 7/12 12:12 AM, Ben Bacarisse wrote:
> Ian Collins<ian-> writes:
>
>> On 09/ 5/12 06:59 PM, jacob navia wrote:
>>> Le 05/09/12 00:13, Ian Collins a écrit :
>>>> Your example proves the point: you test the malloc, but assume the VLA.
>>>
>>> int fn(void)
>>> {
>>> int i;
>>> }
>>>
>>> You do not test for "int i;"
>>>
>>> We should ban then all stack allocation?
>>>
>>> What are you saying actually? I do not understand what you want.
>>
>> VLAs are a vulnerability waiting to happen. Not as bad as gets, but
>> dodgy none the less.
>
> I don't understand this. I need more information. My guess is that you
> are referring to environments that don't check stack accesses, but
> that's not really the fault of the language feature.

In the smaller embedded world (without protected memory), whose are the
norm.

--
Ian Collins

Ian Collins <ian-> writes:

> On 09/ 7/12 12:12 AM, Ben Bacarisse wrote:
>> Ian Collins<ian-> writes:
>>
>>> On 09/ 5/12 06:59 PM, jacob navia wrote:
>>>> Le 05/09/12 00:13, Ian Collins a écrit :
>>>>> Your example proves the point: you test the malloc, but assume the VLA.
>>>>
>>>> int fn(void)
>>>> {
>>>> int i;
>>>> }
>>>>
>>>> You do not test for "int i;"
>>>>
>>>> We should ban then all stack allocation?
>>>>
>>>> What are you saying actually? I do not understand what you want.
>>>
>>> VLAs are a vulnerability waiting to happen. Not as bad as gets, but
>>> dodgy none the less.
>>
>> I don't understand this. I need more information. My guess is that you
>> are referring to environments that don't check stack accesses, but
>> that's not really the fault of the language feature.
>
> In the smaller embedded world (without protected memory), whose are
> the norm.

You mean VLAs larger than typical stack allocations are not safe in some
environments? That's very different to "VLAs are a vulnerability
waiting to happen".

--
Ben.

Ian Collins <ian-> writes:

> On 09/ 7/12 12:16 AM, Ben Bacarisse wrote:
>> Ian Collins<ian-> writes:
>>
>>> On 09/ 6/12 02:57 AM, Malcolm McLean wrote:
>> <snip>
>>>> What he is saying is that you test whether the call to malloc() has
>>>> succeeded, but simply assume that the vla allocation has succeeded.
>>>> But it's not a very good point. If you set a cap on the amount that
>>>> can be allocated on the stack, you can know that the stack won't be
>>>> breached, assuming non-recursive functions. That does raise the
>>>> issue, however, why use a vla at all, since you might as well
>>>> allocate the maximum as a fixed buffer? Arguably a vla provides
>>>> better documentation.
>>>
>>> It may provides better documentation, but it precludes static analysis
>>> of stack usage.
>>
>> Sorry, I'm repeating myself! How does a VLA preclude static analysis of
>> stack usage?
>
> Because you don't know until run time how long it will be. If you
> did, you wouldn't need a variable length.

I'm still lost. Static analysis can be done when some aspects of what's
being analysed depends on input, can't it? When I prove termination of
a loop, that's static analysis is it not? The proof can be often done
even when the loop conditions and execution depend on input. It would
be rather pointless otherwise.

--
Ben.