But C also reqs an obj of size n*m be produced, or calloc fail. Since the former is not possible, latter is mandatory.
-
-
-
Replying to @ch3root
because of the definitions of size_t and of SIZE_MAX
2 replies 0 retweets 0 likes -
Replying to @volatile_void @ch3root
@RichFelker, I don't think you can deduce that the allocation is not possible. So calloc is free to fail or not.1 reply 0 retweets 0 likes -
C std does a very poor job of making reqs like this 100% clear, but size_t needs to be able to repr any obj size
2 replies 0 retweets 1 like -
7.19¶4 suggests that "supporting large objects" would make it "necessary" for size_t to be a larger type.
1 reply 0 retweets 1 like -
Replying to @RichFelker @ch3root
This all what they put under "quality of the implementation", so this is not mandatory.
1 reply 0 retweets 1 like -
We should always keep in mind that a "valid" but "low-quality" impl. is free to only compile one fixed program.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @ch3root
That doesn't catch it, I think. Oldish segmented platforms could have 16 bit size_t and larger dynamic allocs
1 reply 0 retweets 0 likes -
No, if your seg'd arch has 16-bit size_t, you can't have individual allocations >64k, just larger total mem.
2 replies 0 retweets 0 likes
For example malloc(20000) can succeed more than 3 times.
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.