Talk:c/types/size t

C11 standard §7.20.3: size_t's maximum value is given by SIZE_MAX and can be as low as 65536. While there can't be an index greater than SIZE_MAX-1, it's not mandated that SIZE_MAX actually equals the size of system memory, even on unsegmented architectures. As such uintptr_t and size_t equivalence on these system is not guaranteed and should be removed (Also it's wasn't really needed; if you need size, use size_t, if you need address use uintptr_t).

A3f.at (talk) 18:53, 13 January 2015 (PST)

If this wiki were just a copy of the ISO standard, it wouldn't be useful. Do you have an architecture in mind where memory model is flat, but size_t is smaller than uintptr_t? --Cubbi (talk) 19:42, 13 January 2015 (PST)

No, I don't know of any. But I can't think of an implementation for a flat architecture that doesn't provide uintptr_t either. I do agree that copy-pasting the standard won't be that useful, but that wasn't my intention.

If we address what's reasonable, I'd say it's reasonable to expect that uintptr_t is available and it's poor style to advocate for using size_t in its stead.

Finishing that paragraphs with a statement that size_t and uintptr_t are synonymous didn't seem right to me. A3f.at (talk) 05:22, 14 January 2015 (PST)

It wasn't intended to be advocating the use of size_t instead of uintptr_t, but rather as a note on why a lot of C89 code (which lacks uintptr_t) used it that way. --Cubbi (talk) 06:30, 14 January 2015 (PST)

Didn't think of C89.. Maybe it should be reinstated but with a different phrasing:

On (flat memory model) architectures (OR having unsegmented addressing) which lack support of uintrptr_t, size_t is commonly used as substitute. While not guaranteed, it should be able to store the value of any pointer.

Hmm that sounds a bit language lawyer'ish. But I think you understand what I intend to say. Regards, A3f.at (talk) 14:25, 15 January 2015 (PST)