@dev_console @FioraAeterna well.. *most* implementations overcommit. i.e. unless you run out of address space malloc() never returns NULL.
-
-
Replying to @oe1cxw
@oe1cxw@fioraaeterna I don’t think it’s fair to punish implementations that are doing The Right Thing for robustness from that perspective.2 replies 0 retweets 1 like -
Replying to @dev_console
@dev_console@FioraAeterna The only sane thing to do would probably just be to silently call abort() I guess?7 replies 0 retweets 0 likes -
Replying to @oe1cxw
@oe1cxw@fioraaeterna But an embedded application can for instance try to make some space by swapping out stuff.1 reply 0 retweets 0 likes -
Replying to @dev_console
@dev_console@FioraAeterna At least for non-embedded: You never now when the OS tries to increase the stack size.. You can run OOM this way.5 replies 0 retweets 1 like -
Replying to @oe1cxw
@oe1cxw@dev_console@FioraAeterna Linux pre-commits 128k stack which is more than good sw should ever use. Safely getting more is tricky.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@dev_console@FioraAeterna There is a lot of good sw that needs more than 128 kB stack. E.g. Python:pic.twitter.com/W1OcxQvqxx
1 reply 0 retweets 0 likes -
Replying to @oe1cxw
@oe1cxw@dev_console@FioraAeterna 136k is probably the default 128k with args/env/auxv too. I usually see 136k in practice.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@dev_console@FioraAeterna fair enough. On my system: clang >200 kB stack size, Xorg >350 kB, exim4 >500 kB, ...1 reply 0 retweets 0 likes -
Replying to @oe1cxw
@oe1cxw@dev_console@FioraAeterna That's rather unfortunate; any of those could crash with SIGSEGV the first time they expand past 136k...1 reply 0 retweets 0 likes
@oe1cxw @dev_console @FioraAeterna And from portability (and just good design) standpoint it's really bad to use lots of stack anyway.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.