Unspecified vs Implementation Defined Behaviors about c-semantics HOT 4 CLOSED

FWIW,

(char)2352352354 is implementation defined (6.3.1.3 in n1570)
while
INT_MAX + 1 is undefined (6.5:5)

They are two distinct problems. The first is a problem in conversion (and
is not overflow), the second is actual overflow.

-Chucky

On Mon, Oct 19, 2015 at 1:09 PM, Manasvi Saxena [email protected]
wrote:

kcc often lists implementation defined behavior as unspecified. The
difference between the two is documented in C11 sec. 3.4.1 and 3.4.4.

Even though it may not be technically wrong to list implementation defined
behavior as unspecified, kcc should be able to distinguish between the two,
just as the standard does.

Consider for instance error code "CCV1", that has message "signed
overflow". kcc categorizes this as unspecified behavior. C11, on the other
hand, in section 6.3.1.3:3 mentions that the error is implementation
defined. Moreover, sec. J.1:1 (a list of unspecified behaviors encountered
in the standard), does not have the error in its original form.

—
Reply to this email directly or view it on GitHub
#134.

from c-semantics.

Oh so that's where that is. Thanks, @ellisonch !

I have been trying to figure out where in the standard signed overflow was declared to be undefined for a while now. Without that information I knew what we had was wrong but I didn't really know what to do about it.

Okay, so:

CEMX3, CEA6, CCV1 should be UNDEF 6.5:5
CCV2 should be IMPL 6.3.1.3:3

from c-semantics.

So, from what I can see, it looks like we've decided to support this by adding a new Implementation defined error category, which is separate from Unspecified errors. This seems like a reasonable solution.

from c-semantics.

Fixed in #131

from c-semantics.