Pointers to VLA's
up vote
3
down vote
favorite
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)
c variable-length-array
asked Nov 18 at 9:00
Keine Lust
26.3k43362
|
show 5 more comments
up vote
3
down vote
favorite
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)
c variable-length-array
asked Nov 18 at 9:00
Keine Lust
26.3k43362
3
It's not PC, but I think the main reason to make VLA's optional is so that MS could pretend they have a standard compliant compiler
– StoryTeller
Nov 18 at 9:02
int (*ptr)[n]is just a pointer to an array of sizen. Thenhere can be completely ignored by the compiler as it has no purpose.int *ptr;is exactly the same.
– Paul Ogilvie
Nov 18 at 9:03
3
@PaulOgilvie - Thenaffects how the pointer arithmetic is done onptr. It most certainly cannot be ignored.
– StoryTeller
Nov 18 at 9:13
2
ptr + xmust be equal to(char*)ptr + x * (sizeof(int[n]))- usual pointer arithmetic in arrays. Same as if the row size was a constant expression. In this case it just isn't.
– StoryTeller
Nov 18 at 9:23
1
All clear. Many thanks.
– Paul Ogilvie
Nov 18 at 9:33
|
show 5 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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)
c variable-length-array
asked Nov 18 at 9:00
Keine Lust
26.3k43362
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)
c variable-length-array
c variable-length-array
asked Nov 18 at 9:00
Keine Lust
26.3k43362
asked Nov 18 at 9:00
Keine Lust
26.3k43362
asked Nov 18 at 9:00
Keine Lust
26.3k43362
asked Nov 18 at 9:00
Keine Lust
26.3k43362
asked Nov 18 at 9:00
Keine Lust
26.3k43362
26.3k43362
3
It's not PC, but I think the main reason to make VLA's optional is so that MS could pretend they have a standard compliant compiler
– StoryTeller
Nov 18 at 9:02
int (*ptr)[n]is just a pointer to an array of sizen. Thenhere can be completely ignored by the compiler as it has no purpose.int *ptr;is exactly the same.
– Paul Ogilvie
Nov 18 at 9:03
3
@PaulOgilvie - Thenaffects how the pointer arithmetic is done onptr. It most certainly cannot be ignored.
– StoryTeller
Nov 18 at 9:13
2
ptr + xmust be equal to(char*)ptr + x * (sizeof(int[n]))- usual pointer arithmetic in arrays. Same as if the row size was a constant expression. In this case it just isn't.
– StoryTeller
Nov 18 at 9:23
1
All clear. Many thanks.
– Paul Ogilvie
Nov 18 at 9:33
|
show 5 more comments
3
It's not PC, but I think the main reason to make VLA's optional is so that MS could pretend they have a standard compliant compiler
– StoryTeller
Nov 18 at 9:02
int (*ptr)[n]is just a pointer to an array of sizen. Thenhere can be completely ignored by the compiler as it has no purpose.int *ptr;is exactly the same.
– Paul Ogilvie
Nov 18 at 9:03
3
@PaulOgilvie - Thenaffects how the pointer arithmetic is done onptr. It most certainly cannot be ignored.
– StoryTeller
Nov 18 at 9:13
2
ptr + xmust be equal to(char*)ptr + x * (sizeof(int[n]))- usual pointer arithmetic in arrays. Same as if the row size was a constant expression. In this case it just isn't.
– StoryTeller
Nov 18 at 9:23
1
All clear. Many thanks.
– Paul Ogilvie
Nov 18 at 9:33
3
3
It's not PC, but I think the main reason to make VLA's optional is so that MS could pretend they have a standard compliant compiler
– StoryTeller
Nov 18 at 9:02
It's not PC, but I think the main reason to make VLA's optional is so that MS could pretend they have a standard compliant compiler
– StoryTeller
Nov 18 at 9:02
int (*ptr)[n] is just a pointer to an array of size n. The n here can be completely ignored by the compiler as it has no purpose. int *ptr; is exactly the same.– Paul Ogilvie
Nov 18 at 9:03
int (*ptr)[n] is just a pointer to an array of size n. The n here can be completely ignored by the compiler as it has no purpose. int *ptr; is exactly the same.– Paul Ogilvie
Nov 18 at 9:03
3
3
@PaulOgilvie - The
n affects how the pointer arithmetic is done on ptr. It most certainly cannot be ignored.– StoryTeller
Nov 18 at 9:13
@PaulOgilvie - The
n affects how the pointer arithmetic is done on ptr. It most certainly cannot be ignored.– StoryTeller
Nov 18 at 9:13
2
2
ptr + x must be equal to (char*)ptr + x * (sizeof(int[n])) - usual pointer arithmetic in arrays. Same as if the row size was a constant expression. In this case it just isn't.– StoryTeller
Nov 18 at 9:23
ptr + x must be equal to (char*)ptr + x * (sizeof(int[n])) - usual pointer arithmetic in arrays. Same as if the row size was a constant expression. In this case it just isn't.– StoryTeller
Nov 18 at 9:23
1
1
All clear. Many thanks.
– Paul Ogilvie
Nov 18 at 9:33
All clear. Many thanks.
– Paul Ogilvie
Nov 18 at 9:33
|
show 5 more comments
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
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..
Nov 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
Nov 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 at 20:28
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
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..
Nov 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
Nov 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 at 20:28
add a comment |
up vote
2
down vote
accepted
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.
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
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..
Nov 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
Nov 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 at 20:28
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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.
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
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.
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
edited Nov 18 at 9:45
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
answered Nov 18 at 9:40
StoryTeller
89.7k12180246
89.7k12180246
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..
Nov 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
Nov 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 at 20:28
add a comment |
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..
Nov 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
Nov 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 at 20:28
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..
Nov 18 at 15:26
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..
Nov 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
Nov 18 at 15:28
@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
Nov 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 at 20: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 at 20:28
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53359275%2fpointers-to-vlas%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
It's not PC, but I think the main reason to make VLA's optional is so that MS could pretend they have a standard compliant compiler
– StoryTeller
Nov 18 at 9:02
int (*ptr)[n]is just a pointer to an array of sizen. Thenhere can be completely ignored by the compiler as it has no purpose.int *ptr;is exactly the same.– Paul Ogilvie
Nov 18 at 9:03
3
@PaulOgilvie - The
naffects how the pointer arithmetic is done onptr. It most certainly cannot be ignored.– StoryTeller
Nov 18 at 9:13
2
ptr + xmust be equal to(char*)ptr + x * (sizeof(int[n]))- usual pointer arithmetic in arrays. Same as if the row size was a constant expression. In this case it just isn't.– StoryTeller
Nov 18 at 9:23
1
All clear. Many thanks.
– Paul Ogilvie
Nov 18 at 9:33