Pelles C forum

Pelles C => Bug reports => Topic started by: Robert on October 05, 2005, 11:00:36 PM

Title: VLA problem
Post by: Robert on October 05, 2005, 11:00:36 PM
The following snippet for setting up a pointer to a VLA
taken from the What are Variable Length Arrays? section of

http://www.comeaucomputing.com/techtalk/c99/

int main()
{
int n = 99
static int (*p)[n];
}

generates

error #2084: Invalid storage class 'static' for 'p' with type ' int

Robert Wishlaw

Robert Wishlaw
Title: VLA problem
Post by: Pelle on October 06, 2005, 10:53:36 PM
It's a known missing C99 feature in Pelles C - not sure if/when I'm going to implement it...

Pelle
Title: VLA problem
Post by: Robert on October 06, 2005, 11:19:34 PM
Pelle:

Thank you for the explanation. I don't need that capability at the moment but I did notice the problem when checking compilers for C99 compliance.
Title: VLA problem
Post by: Pelle on October 07, 2005, 06:51:58 PM
I currently use the _alloca() function to implement VLA's - which isn't 100% correct. It works for the more common cases - but your case, and a few more, can't be handled with this function...

Some day I will have to redesign the whole approach.

Pelle
Title: Re: VLA problem
Post by: MrBcx on November 22, 2019, 03:50:41 AM
Hi Pelle,

I am out of my depth here but I thought I'd run this by you anyway.

An associate was using stb_image (a png library) and it appeared to work okay for sizes up to 800x800 ... anything larger would crash the app.

The library used a VLA for the bitmap data. 

I read your earlier explanation that you use _alloca() to implement VLA allocation and your desire to rework things in the future.

I decided to use the _alloca() directly, instead of relying on VLA on my friends code  I got exactly the same results.

Next I decided to use malloc() instead of _alloca() and the bug and crash went away.

The application compiled with LccWin32 behaved exactly the same ways as with Pelles before and after my fix.

The app compiled with Mingw32 performed correctly using VLA, so it didn't need the fix.

This all leads me to think you and Jacob are using similar approaches to VLA implementation and perhaps your  _alloca() functions are flawed. 
I don't have access to your sources, so this is all speculation on my part.

Do whatever you want to with this information.

Peace!
MrBcx
Title: Re: VLA problem
Post by: frankie on November 22, 2019, 08:57:59 AM
Hello Robert
Not sure, I'll check, but I imagine that the _alloca() will deploy variables on the local stack space.
As fast work-around you can try to compile the exe with the linker switch '/STACK=0XA00000' to assign a bigger stack size (standar value is 1MB). In the example I put 10MB circa.
Title: Re: VLA problem
Post by: MrBcx on November 22, 2019, 03:16:42 PM
Hi Frankie ... actually, this is Kevin, not Robert.

Robert and I have been BCX collaborators for 20 years.

(edit #1)  I tried your suggestion and increasing the stack/heap solved the problem.  Thank you very much!
(edit #2)  Applying a similar stack statement to LccWin32 also solved the problem.

The problem I see is that the only certain time one will know if an insufficient stack/heap allocation has been allocated is when one's program crashes.


I don't knowingly use VLA's but if there is an issue using them, there could be dragons waiting at the gates.



 
Title: Re: VLA problem
Post by: frankie on November 23, 2019, 03:42:54 PM
Quote from: MrBcx on November 22, 2019, 03:16:42 PM
Hi Frankie ... actually, this is Kevin, not Robert.
Hello Kevin, my mistake sorry.

Quote from: MrBcx on November 22, 2019, 03:16:42 PM
I tried your suggestion and increasing the stack/heap solved the problem.  Thank you very much!
Applying a similar stack statement to LccWin32 also solved the problem.
You're welcome!
I'm very happy that this fix worked.
Anyway as I said the _alloca() function use local stack space to allocate room, but while MingW version expands the stack in function of the requested memory space, PellesC and LccWin32 fails to do.

Quote from: MrBcx on November 22, 2019, 03:16:42 PM
I don't knowingly use VLA's but if there is an issue using them, there could be dragons waiting at the gates.
The C-runtime library need a tweek to fix the problem, but this only for the sake of bad programming!.
It is very bad practice to allocate big dynamic space on the processor stack, wrong and prone to errors. See:

IMHO it is the stb_image library that needs a fix!  ;)
Title: Re: VLA problem
Post by: Pelle on November 24, 2019, 04:41:56 PM
VLAs were introduced in the C99 standard as a mandatory feature but made optional in the C11 standard (see __STDC_NO_VLA__), basically because "everyone" hated them. There is no way to make it safe and reliable on all platforms. On some platforms the ambitious implementations may add extra runtime checks (and overhead) to catch the stack overflow, but there are no requirements to do so.

The application could do it's own sanity check on the size before defining a VLA, but it should be a fairly small value since the stack is a limited resource (even if you can increase it a bit...)

Title: Re: VLA problem
Post by: MrBcx on November 28, 2019, 04:59:42 AM
Quote from: Pelle on November 24, 2019, 04:41:56 PM
VLAs were introduced in the C99 standard as a mandatory feature but made optional in the C11 standard (see __STDC_NO_VLA__), basically because "everyone" hated them. There is no way to make it safe and reliable on all platforms. On some platforms the ambitious implementations may add extra runtime checks (and overhead) to catch the stack overflow, but there are no requirements to do so.

The application could do it's own sanity check on the size before defining a VLA, but it should be a fairly small value since the stack is a limited resource (even if you can increase it a bit...)

Thank you for the helpful explanation Pelle ... " basically because "everyone" hated them."   And now I hate them too   ;D