| commit | 41b3c7a50727f715111d09af982e2e9a0deeb688 | |
| author | James Lyon <jamesly0n@hotmail.com> | |
| Sat, 27 Apr 2013 19:39:34 +0000 (27 20:39 +0100) | ||
| committer | James Lyon <jamesly0n@hotmail.com> | |
| Sat, 27 Apr 2013 21:58:52 +0000 (27 22:58 +0100) | ||
| tree | 0192d5295fd3cfca625ba769be2188ef72b15d64 | treesnapshot (tar.gz zip) |
| parent | 6ee366e765483f6b48537d97fc81ae56f13d1b7f | commitdiff |
Improved variable length array support.
VLA storage is now freed when it goes out of scope. This makes it
possible to use a VLA inside a loop without consuming an unlimited
amount of memory.
Combining VLAs with alloca() should work as in GCC - when a VLA is
freed, memory allocated by alloca() after the VLA was created is also
freed. There are some exceptions to this rule when using goto: if a VLA
is in scope at the goto, jumping to a label will reset the stack pointer
to where it was immediately after the last VLA was created prior to the
label, or to what it was before the first VLA was created if the label
is outside the scope of any VLA. This means that in some cases combining
alloca() and VLAs will free alloca() memory where GCC would not.
VLA storage is now freed when it goes out of scope. This makes it
possible to use a VLA inside a loop without consuming an unlimited
amount of memory.
Combining VLAs with alloca() should work as in GCC - when a VLA is
freed, memory allocated by alloca() after the VLA was created is also
freed. There are some exceptions to this rule when using goto: if a VLA
is in scope at the goto, jumping to a label will reset the stack pointer
to where it was immediately after the last VLA was created prior to the
label, or to what it was before the first VLA was created if the label
is outside the scope of any VLA. This means that in some cases combining
alloca() and VLAs will free alloca() memory where GCC would not.
12 files changed: