On Mar 30, 2007, at 19:51, Paul Eggert wrote:
Geoff Clare <[EMAIL PROTECTED]> writes:
Paul Eggert <[EMAIL PROTECTED]> wrote, on 30 Mar 2007:
Picky, picky. Let me restate it as "if the code ... outputs
"SSIZE_MAX wrong" (through normal execution, not undefined
behaviour),
Fine, but the point is that there's no portable way for an application
to determine whether adding 1 to a ssize_t variable will have "normal
execution" if the variable's value is SSIZE_MAX.
Perhaps not with x+1, but what about x|(1<<b) where 1<<b is known to
be less than x? I think the constraints on integer representations
guarantee that the result will be a valid positive value equal to or
larger than x in that same integer type. From that, I think you can
conclude that we can reach some 2**n-1 value, and possibly get
"SSIZE_MAX wrong" without invoking undefined behavior, if SSIZE_MAX
isn't of the form 2**n-1. It could still be 2**13-1 for a 16-bit
type, but not 52k. (Indeed, the C99 spec also seems to allow for a 2-
byte integer type with 13 bits of precision, one sign bit, and two
padding bits, and I'm not sure you could distinguish that from a
normal 16-bit short without wandering into undefined behavior.)
Ken
