3 ms·
>size_t is defined as "an integer capable of holding the >largest array index" >>No, it isn't. Could anyone elaborate? I don't see how could someone allocate
by xcgvgh 11y ago
>size_t is defined as "an integer capable of holding the >largest array index"
>>No, it isn't.
Could anyone elaborate?
I don't see how could someone allocate more than SIZE_MAX bytes with (m/c/re)alloc since they all take size_t as an argument, and size_t is the type used for defining array sizes. Thus size_t can hold the largest array index (in fact it can hold the largest_index+1 since arrays are zero based). Any counterarguments?
- chrisseaton 11y agoMaybe he's taking it very literally, as I think size_t is literally defined as 'the integer type of the result of the sizeof operator'. So it literally isn't defined as 'an integer capable of holding the >largest array index' as that's not the definition and words they use.
- viraptor 11y agoBut if sizeof returns size_t, then your can't have indexes larger than that. Otherwise you could point beyond the largest in-memory object possible. (Using smallest (byte) indexing) But yes, he may be arguing the definition rather than meaning.
- dietrichepp 11y agoThe counterargument is actually relatively simple, because it's an argument over what the definition of size_t is, and you can simply go look to the C standard and find the definition there.
- xcgvgh 11y agoI understand. If I change the argument to: size_t is capable of holding the largest array index", then this must be correct, or is there still something I missed?
- dietrichepp 11y agoYes, that's correct.