Secure coding and formatted input

Memloop posted a link to an article on secure coding in C that recommended that one "use strtol() or a related function to convert a string token to an integer". Reading the C++ version of that article, I see that formatted input with operator>> is criticised as it "has undefined behavior if the value of the result of this operation cannot be represented as an integer". Is this true?

Empirical evidence with the MinGW port of g++ 3.4.5 and MSVC9 show that formatted input with operator>> is able to detect overflow when reading to an integer variable, but such evidence is insufficient when contemplating undefined behaviour.

Quote:

---

Originally Posted by ISO/IEC 14882:2003(E)

22.2.2.1.2 num_get virtual functions
...
11
Stage 3: The result of stage 2 processing can be one of
— A sequence of chars has been accumulated in stage 2 that is converted (according to the rules of scanf) to a value of the type of val. This value is stored in val and ios_base::goodbit is stored in err.
— The sequence of chars accumulated in stage 2 would have caused scanf to report an input failure. ios_base::failbit is assigned to err.

---

Seems to me the article is wrong.

gg

Well, it seems to be based on this: https://www.securecoding.cert.org/co...ossible+inputs

Quote:

---

Originally Posted by ISO/IEC 9899:1999 (E)

7.19.6.2 The fscanf function
...
10
Except in the case of a % specifier, the input item (or, in the case of a %n directive, the count of input characters) is converted to a type appropriate to the conversion specifier. If the input item is not a matching sequence, the execution of the directive fails: this condition is a matching failure. Unless assignment suppression was indicated by a *, the result of the conversion is placed in the object pointed to by the first argument following the format argument that has not already received a conversion result. If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.

---

gg

Still, I don't see anything about how the >> operator handles overflows.

It handles it "according to the rules of scanf".

The rules for scanf (in C99 at least) say: "... if the result of the conversion cannot be represented in the object, the behavior is undefined."

gg

It seems to me they are claiming to have invented a wheel named 'always perform error handling', which is nothing new. I think in any case where this code would break, the rest of the program would have to be exceptionally sloppy to begin with, but thats just my 2¢

That's what I thought. I guess that means you can't use C++ streams when dealing with numeric input ...

Quote:

---

Originally Posted by abachler

I think in any case where this code would break, the rest of the program would have to be exceptionally sloppy to begin with, but thats just my 2¢

---

That is what they admit as well: "While it is rare for a violation of this recommendation to result in a security vulnerability, it can easily result in lost or misinterpreted data." However, it seems to me that the "lost or misinterpreted data" is likely to be the result of either a user input mistake or malicious input, upon which just documenting the program behaviour in such cases would mean that it no longer constitutes "lost or misinterpreted data".

Quote:

---

Originally Posted by Memloop

I guess that means you can't use C++ streams when dealing with numeric input ...

---

No, it just means that you cannot use formatted input with C++ streams for handling numeric input if you do not want to risk undefined behaviour. It seems to me that the undefined behaviour does not make sense: both implementations that I tested have behaviour that makes sense, and perhaps it is a bug in the Standard(s) to fail to standardise in favour of that.