http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> 2012-05-06 04:11:03
UTC ---
I would lean towards marking this one invalid. Under normal circumstances (and
I would argue, under ALL conditions, on a high-quality implementation), objects
cannot be larger than SIZE_MAX/2. This is because ptrdiff_t has been chosen to
be the signed type corresponding to size_t, and if objects larger than
SIZE_MAX/2 were allowed, valid pointer subtractions would overflow the signed
ptrdiff_t and result in undefined behavior.
There are three ways of addressing this issue; either:
(1) you say "subtracting pointers is unsafe unless the application makes an
effort to ensure that no huge objects exist" even though that's hard to do in
any portable way; OR
(2) you disallow objects sufficiently large that ptrdiff_t would overflow; OR
(3) you make ptrdiff_t a larger type (e.g. 64-bit on 32-bit systems). But this
is not an option since you're always dealing with an already-defined ABI.
If you take option (1), large objects (>SIZE_MAX/2) are already extremely
dangerous and so the additional wrapping issue in GCC's internal representation
is a really small matter in comparison. If you take option (2), offsets can
always be interpreted as the signed type.
