3 ms·

A VLA is by definition on the stack; if you allocate memory in the heap you wouldn't need this feature in the first place.

by saurik 5y ago

geofft 5y ago
Right, but I think there's a valid question of why you need to ban strings entirely, and why you can't have variable-length allocations provided you use the heap instead of VLAs. (You can.)
- foota 5y ago
  Right, that's what I was saying. The statement "The kernel has limited stack space and isn't good at growing it." felt like a non sequitur when followed by "QNX got this right. No strings in the kernel. Everything is either fixed-length or in user space. A privileged program in user space deals with filenames and such." Whether or not you use fixed space is orthogonal to whether you use VLA.
josefx 5y ago
> A VLA is by definition on the stack Do you have a source for that claim? The C11 standard notes that memory associated with a variable length array can be "squandered" by a longjmp, as far as I understand that shouldn't happen with stack allocation. Most implementations may use stack allocation, leading to the stackoverflow problems described in the article. However as far as I can tell the standard doesn't require this.
- unnah 5y ago
  Right, VLA is not just syntactic sugar for alloca, it's also syntactic sugar for accessing and passing around multi-dimensional arrays. The latter two work perfectly fine with heap-allocated arrays. In C89 the ability to pass multi-dimensional arrays to functions was not very useful, since the inner dimensions could not vary at runtime. Fixing this was the main point of the VLA feature, at least for people who work on array data. It would be even more useful, had they supported strided arrays...
- saurik 5y ago
  Huh. I've now read the maybe-original article on this subject from 1994-- http://www.open-std.org/jtc1/sc22/wg14/www/docs/n317.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n317.pdf --and have also re-read this conversation thread, and yeah: I agree.

A VLA is by definition on the stack; if you allocate memory in the heap you wouldn't need this feature in the first place.

by saurik 5y ago

A VLA is by definition on the stack; if you allocate memory in the heap you wouldn't need this feature in the first place.

geofft 5y ago

Right, but I think there's a valid question of why you need to ban strings entirely, and why you can't have variable-length allocations provided you use the heap instead of VLAs. (You can.)

foota 5y ago
Right, that's what I was saying. The statement "The kernel has limited stack space and isn't good at growing it." felt like a non sequitur when followed by "QNX got this right. No strings in the kernel. Everything is either fixed-length or in user space. A privileged program in user space deals with filenames and such." Whether or not you use fixed space is orthogonal to whether you use VLA.

josefx 5y ago

> A VLA is by definition on the stack Do you have a source for that claim? The C11 standard notes that memory associated with a variable length array can be "squandered" by a longjmp, as far as I understand that shouldn't happen with stack allocation. Most implementations may use stack allocation, leading to the stackoverflow problems described in the article. However as far as I can tell the standard doesn't require this.

unnah 5y ago
Right, VLA is not just syntactic sugar for alloca, it's also syntactic sugar for accessing and passing around multi-dimensional arrays. The latter two work perfectly fine with heap-allocated arrays. In C89 the ability to pass multi-dimensional arrays to functions was not very useful, since the inner dimensions could not vary at runtime. Fixing this was the main point of the VLA feature, at least for people who work on array data. It would be even more useful, had they supported strided arrays...
saurik 5y ago
Huh. I've now read the maybe-original article on this subject from 1994-- http://www.open-std.org/jtc1/sc22/wg14/www/docs/n317.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n317.pdf --and have also re-read this conversation thread, and yeah: I agree.