User talk:Superlokkus

atoi error handling

I had reverted your change to atoi, but I think I see where your reading is coming from: The standardese regarding atoi comes from three paragraphs:

• 7.22.1/1 "If the value of the result cannot be represented, the behavior is undefined."
• 7.22.1.2/2 "Except for the behavior on error, they are equivalent to (int)strtol(nptr, (char **)NULL, 10)"
• 7.22.1.4/8 "If no conversion could be performed, zero is returned. If the correct value is outside the range of representable values... (irrelevant because overruled by 7.22.1/1)

My reading is that the differences in error handling mentioned in 7.22.1.2/2 are specified by 7.22.1/1, which only lists the difference for overflow, and not for non-integer.

I suppose you could read it as 7.22.1.2/2 ruling all behavior on error undefined and 7.22.1/1 clarifying that behavior for one of the possible errors as "undefined", but that would render 7.22.1/1 meaningless. I'll check in the issue trackers if anyone brought this up before. --Cubbi (talk) 07:32, 11 March 2016 (PST)

I don't see an issue, but for what it's worth, CERT supports my reading: INT06-C: "Unfortunately, atoi() and related functions lack a mechanism for reporting errors for invalid values. Specifically, the atoi(), atol(), and atoll() functions * Do not need to set errno on an error * Have undefined behavior if the value of the result cannot be represented * Return 0 if the string does not represent an integer, which is indistinguishable from a correctly formatted, zero-denoting input string".

This was also brought up in comp.std.c in 2006 --Cubbi (talk) 14:15, 11 March 2016 (PST)

I guess Cubbi was right. Thanks Cubbi :-) Superlokkus