What libc? Looks like there's still/again an integer overflow in calloc(), or am I reading this wrong?
-
-
7.19¶4 suggests that "supporting large objects" would make it "necessary" for size_t to be a larger type.
-
This all what they put under "quality of the implementation", so this is not mandatory.
-
We should always keep in mind that a "valid" but "low-quality" impl. is free to only compile one fixed program.
-
That doesn't catch it, I think. Oldish segmented platforms could have 16 bit size_t and larger dynamic allocs
-
No, if your seg'd arch has 16-bit size_t, you can't have individual allocations >64k, just larger total mem.
-
I don't see where this would be required. size_t is defined via sizeof.
-
Specification of lib functions. E.g. strlen is specified to return length, not "length, converted to size_t".
-
If you want to just say it's UB or unspecified result if it doesn't fit, that's even more awful and unusable.
- 8 more replies
New conversation -
-
-
Otherwise you would have all sorts of horrible things like wrong results from strlen, strcspn, etc.
-
If I work with ints I don't care about strlen etc. Problems with strings shouldn't preclude numeric work.
End of conversation
New conversation -
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.