7

As you may know, VLA's haves pros and cons and they are optional in C11.

I suppose that the main reason to make VLA's optional is: "the stack can blow up":

int arr[n]; /* where n = 1024 * 1024 * 1024 */

but what about pointer to VLA's?

int m, n;

scanf("%d %d", &m, &n);

int (*ptr)[n] = malloc(sizeof(int [m][n]));

In this case, there is no risk to blow up the stack, and IMO they are extremely useful.

My question is:

Could the committee have preserved pointers to VLA's, making the VLA's to non-pointer types optional?

Or one thing implies the other?

(Excuse my poor english)

David Ranieri
  • 39,972
  • 7
  • 52
  • 94

1 Answers1

3

Preserving pointers to variably modifiable types would require an implementation to support about 90% of the VLA specification. The reason is the effective type rule:

6.5 Expressions

¶6 The effective type of an object for an access to its stored value is the declared type of the object, if any. If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

After an access via ptr to the malloced memory, the effective type of the object is a VLA type. So an implementation will need to support those semantics correctly. The only thing that can be left "optional" is the ability to declare VLA's with automatic storage duration...

int boo[n];

... which is kinda silly. If an implementation supports most of VLA semantics for dynamically allocated objects, it may as well allow declaring them as objects with automatic storage duration. The committee wanted it to be truly optional, so that means pointers to VLA types had to go too.

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
  • I don't think this answer is correct. There is no work at all in implementing effective type rules except to perform optimization based on non-aliasing, and an implementor can omit whichever rules they like, because the rules apply to conforming applications not implementations. On the other hand, automatic storage VLAs necessarily interact with low-level backend stuff. – R.. GitHub STOP HELPING ICE Nov 18 '18 at 15:26
  • @R.. - The question was about the standard's pov. The amount of specification that will need to be hacked and slashed around the effective type rule looks non-trivial to me. Of course implementations can implement whatever. – StoryTeller - Unslander Monica Nov 18 '18 at 15:28
  • The quote is mostly irrelevant as you can never store a value with an array type into an object -- you can only store values with the array's element type into elements of the array. Similarly, you can never access a value with an array type -- only elements of the array. I think StoryTeller's comment identifies the main reason. – Chris Dodd Nov 18 '18 at 20:28
  • I would say that 90% of all complains about VLAs and the implementation issues (like extra complexity and non-determinism of stack management) comes from automatic VLAs. IMO, it is a very good decision from C committee to make VLA types mandatory in C23. Only automatic VLA will stay optional. – tstanisl Jul 15 '22 at 08:12