NO

Author Topic: VLA problem  (Read 2994 times)

Offline Robert

  • Member
  • *
  • Posts: 188
VLA problem
« 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

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1998
    • http://www.smorgasbordet.com
VLA problem
« Reply #1 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
/Pelle

Offline Robert

  • Member
  • *
  • Posts: 188
VLA problem
« Reply #2 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.

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1998
    • http://www.smorgasbordet.com
VLA problem
« Reply #3 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
/Pelle

Offline MrBcx

  • Global Moderator
  • Member
  • *****
  • Posts: 51
    • http://www.bcxgurus.com/
Re: VLA problem
« Reply #4 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

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1730
Re: VLA problem
« Reply #5 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.

Offline MrBcx

  • Global Moderator
  • Member
  • *****
  • Posts: 51
    • http://www.bcxgurus.com/
Re: VLA problem
« Reply #6 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.



 
« Last Edit: November 22, 2019, 05:38:03 pm by MrBcx »

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1730
Re: VLA problem
« Reply #7 on: November 23, 2019, 03:42:54 pm »
Hi Frankie ... actually, this is Kevin, not Robert.
Hello Kevin, my mistake sorry.

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.

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!  ;)
« Last Edit: November 23, 2019, 03:55:16 pm by frankie »

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1998
    • http://www.smorgasbordet.com
Re: VLA problem
« Reply #8 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...)

/Pelle

Offline MrBcx

  • Global Moderator
  • Member
  • *****
  • Posts: 51
    • http://www.bcxgurus.com/
Re: VLA problem
« Reply #9 on: November 28, 2019, 04:59:42 am »
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