Why am I limited to an arbitrary small ( array size when initializing an array with a const length in C?












0















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.










share|improve this question


















  • 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
















0















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.










share|improve this question


















  • 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














0












0








0








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.










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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














  • 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












1 Answer
1






active

oldest

votes


















3














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.






share|improve this answer


























  • 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











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
});


}
});














draft saved

draft discarded


















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









3














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.






share|improve this answer


























  • 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
















3














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.






share|improve this answer


























  • 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














3












3








3







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 25 '18 at 8:23

























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



















  • 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




















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

404 Error Contact Form 7 ajax form submitting

How to know if a Active Directory user can login interactively

TypeError: fit_transform() missing 1 required positional argument: 'X'