Why am I limited to an arbitrary small ( array size when initializing an array with a const length in C?
Note: I have seen In C, why can't a const variable be used as an array size initializer? already, but this doesn't quite answer my question (or I am not understanding it fully).
This works:
int main() {
const long COUNT = 1048106;
int nums[COUNT];
return 0;
}
This crashes:
int main() {
const long COUNT = 1048106000;
int nums[COUNT];
return 0;
}
I have read that this is actually an inappropriate use of const to begin with (since it means read-only, not evaluated at compile time).
So I am happy to use #define or whatnot instead, but still, it bothers me why this works for some lengths but not but not any higher.
c
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
add a comment |
Note: I have seen In C, why can't a const variable be used as an array size initializer? already, but this doesn't quite answer my question (or I am not understanding it fully).
This works:
int main() {
const long COUNT = 1048106;
int nums[COUNT];
return 0;
}
This crashes:
int main() {
const long COUNT = 1048106000;
int nums[COUNT];
return 0;
}
I have read that this is actually an inappropriate use of const to begin with (since it means read-only, not evaluated at compile time).
So I am happy to use #define or whatnot instead, but still, it bothers me why this works for some lengths but not but not any higher.
c
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
1
A typical Unix program has 8 MiB of stack; a typical Windows program has 1 MiB of stack. Your big size array blows the stack limits out of the water. Either use a global variable or use dynamic memory allocation. Remember: the stack is finite and small (and error recovery from a blown stack is problematic at best). (The first version allocates about 4 MiB on stack; that suggests you're running on a Unix-like system, Linuex for example. The second version tries to allocate 4 GiB or so on stack — that's not gonna fly anywhere normal.)
– Jonathan Leffler
Nov 25 '18 at 8:16
IMO, there use of a VLA has no particular relevance; what matters is the size of the array, not whether it is a VLA or not.
– Jonathan Leffler
Nov 25 '18 at 8:19
add a comment |
Note: I have seen In C, why can't a const variable be used as an array size initializer? already, but this doesn't quite answer my question (or I am not understanding it fully).
This works:
int main() {
const long COUNT = 1048106;
int nums[COUNT];
return 0;
}
This crashes:
int main() {
const long COUNT = 1048106000;
int nums[COUNT];
return 0;
}
I have read that this is actually an inappropriate use of const to begin with (since it means read-only, not evaluated at compile time).
So I am happy to use #define or whatnot instead, but still, it bothers me why this works for some lengths but not but not any higher.
c
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
Note: I have seen In C, why can't a const variable be used as an array size initializer? already, but this doesn't quite answer my question (or I am not understanding it fully).
This works:
int main() {
const long COUNT = 1048106;
int nums[COUNT];
return 0;
}
This crashes:
int main() {
const long COUNT = 1048106000;
int nums[COUNT];
return 0;
}
I have read that this is actually an inappropriate use of const to begin with (since it means read-only, not evaluated at compile time).
So I am happy to use #define or whatnot instead, but still, it bothers me why this works for some lengths but not but not any higher.
c
c
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
asked Nov 25 '18 at 7:35
tacos_tacos_tacostacos_tacos_tacos
5,923855107
5,923855107
1
A typical Unix program has 8 MiB of stack; a typical Windows program has 1 MiB of stack. Your big size array blows the stack limits out of the water. Either use a global variable or use dynamic memory allocation. Remember: the stack is finite and small (and error recovery from a blown stack is problematic at best). (The first version allocates about 4 MiB on stack; that suggests you're running on a Unix-like system, Linuex for example. The second version tries to allocate 4 GiB or so on stack — that's not gonna fly anywhere normal.)
– Jonathan Leffler
Nov 25 '18 at 8:16
IMO, there use of a VLA has no particular relevance; what matters is the size of the array, not whether it is a VLA or not.
– Jonathan Leffler
Nov 25 '18 at 8:19
add a comment |
1
A typical Unix program has 8 MiB of stack; a typical Windows program has 1 MiB of stack. Your big size array blows the stack limits out of the water. Either use a global variable or use dynamic memory allocation. Remember: the stack is finite and small (and error recovery from a blown stack is problematic at best). (The first version allocates about 4 MiB on stack; that suggests you're running on a Unix-like system, Linuex for example. The second version tries to allocate 4 GiB or so on stack — that's not gonna fly anywhere normal.)
– Jonathan Leffler
Nov 25 '18 at 8:16
IMO, there use of a VLA has no particular relevance; what matters is the size of the array, not whether it is a VLA or not.
– Jonathan Leffler
Nov 25 '18 at 8:19
1
1
A typical Unix program has 8 MiB of stack; a typical Windows program has 1 MiB of stack. Your big size array blows the stack limits out of the water. Either use a global variable or use dynamic memory allocation. Remember: the stack is finite and small (and error recovery from a blown stack is problematic at best). (The first version allocates about 4 MiB on stack; that suggests you're running on a Unix-like system, Linuex for example. The second version tries to allocate 4 GiB or so on stack — that's not gonna fly anywhere normal.)
– Jonathan Leffler
Nov 25 '18 at 8:16
A typical Unix program has 8 MiB of stack; a typical Windows program has 1 MiB of stack. Your big size array blows the stack limits out of the water. Either use a global variable or use dynamic memory allocation. Remember: the stack is finite and small (and error recovery from a blown stack is problematic at best). (The first version allocates about 4 MiB on stack; that suggests you're running on a Unix-like system, Linuex for example. The second version tries to allocate 4 GiB or so on stack — that's not gonna fly anywhere normal.)
– Jonathan Leffler
Nov 25 '18 at 8:16
IMO, there use of a VLA has no particular relevance; what matters is the size of the array, not whether it is a VLA or not.
– Jonathan Leffler
Nov 25 '18 at 8:19
IMO, there use of a VLA has no particular relevance; what matters is the size of the array, not whether it is a VLA or not.
– Jonathan Leffler
Nov 25 '18 at 8:19
add a comment |
1 Answer
1
active
oldest
votes
Both your array declarations are in fact variable length array declarations. COUNT is not a constant expression in C, despite being const.
But regardless, the bigger size simply exceeds your implementation's limits, overflowing the call stack where those locals are usually allocated. Though I suspect this behavior will go away should you compile with optimizations. A compiler can easily deduce that nums isn't used in your snippet, and remove it entirely.
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
1
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
|
show 2 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f53465543%2fwhy-am-i-limited-to-an-arbitrary-small-array-size-when-initializing-an-array-w%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Both your array declarations are in fact variable length array declarations. COUNT is not a constant expression in C, despite being const.
But regardless, the bigger size simply exceeds your implementation's limits, overflowing the call stack where those locals are usually allocated. Though I suspect this behavior will go away should you compile with optimizations. A compiler can easily deduce that nums isn't used in your snippet, and remove it entirely.
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
1
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
|
show 2 more comments
Both your array declarations are in fact variable length array declarations. COUNT is not a constant expression in C, despite being const.
But regardless, the bigger size simply exceeds your implementation's limits, overflowing the call stack where those locals are usually allocated. Though I suspect this behavior will go away should you compile with optimizations. A compiler can easily deduce that nums isn't used in your snippet, and remove it entirely.
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
1
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
|
show 2 more comments
Both your array declarations are in fact variable length array declarations. COUNT is not a constant expression in C, despite being const.
But regardless, the bigger size simply exceeds your implementation's limits, overflowing the call stack where those locals are usually allocated. Though I suspect this behavior will go away should you compile with optimizations. A compiler can easily deduce that nums isn't used in your snippet, and remove it entirely.
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
Both your array declarations are in fact variable length array declarations. COUNT is not a constant expression in C, despite being const.
But regardless, the bigger size simply exceeds your implementation's limits, overflowing the call stack where those locals are usually allocated. Though I suspect this behavior will go away should you compile with optimizations. A compiler can easily deduce that nums isn't used in your snippet, and remove it entirely.
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
edited Nov 25 '18 at 8:23
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
answered Nov 25 '18 at 7:38
StoryTellerStoryTeller
99.6k12201271
99.6k12201271
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
1
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
|
show 2 more comments
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
1
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
Ok, awesome. So this is a stack overflow because the stack doesn't have enough space to address that big an array?
– tacos_tacos_tacos
Nov 25 '18 at 7:39
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
@tacos_tacos_tacos - Yup. You found its limit. Though it's worth noting the most compilers will let you set the size of the call stack for the generated program, via compilation flags.
– StoryTeller
Nov 25 '18 at 7:41
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
I don't think the behaviour will go away. Even if it is a const.length array, it's still on the stack.
– glglgl
Nov 25 '18 at 7:43
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
@glglgl - Compilers are free to optimize as they please under the as-if rule. And if a variable isn't used, the program can be successfully translated as-if the variable was never declared.
– StoryTeller
Nov 25 '18 at 7:44
1
1
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
The fact that it is a VLA is tangential to the crash. Changing the numbers to enumeration constants so it isn't a VLA would still lead to a crash — because the stack size on Unix is normally limited to about 8 MiB and on Windows to about 1 MiB, and the first code tries to allocate about 4 MiB and the second about 4 GiB. That the first works suggests the OP is running on a Unix-ish system (Linux, macOS, BSD, Solaris, AIX, HP-UX, …).
– Jonathan Leffler
Nov 25 '18 at 8:21
|
show 2 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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%2f53465543%2fwhy-am-i-limited-to-an-arbitrary-small-array-size-when-initializing-an-array-w%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
1
A typical Unix program has 8 MiB of stack; a typical Windows program has 1 MiB of stack. Your big size array blows the stack limits out of the water. Either use a global variable or use dynamic memory allocation. Remember: the stack is finite and small (and error recovery from a blown stack is problematic at best). (The first version allocates about 4 MiB on stack; that suggests you're running on a Unix-like system, Linuex for example. The second version tries to allocate 4 GiB or so on stack — that's not gonna fly anywhere normal.)
– Jonathan Leffler
Nov 25 '18 at 8:16
IMO, there use of a VLA has no particular relevance; what matters is the size of the array, not whether it is a VLA or not.
– Jonathan Leffler
Nov 25 '18 at 8:19