如果C ++的atoi（）允许未定义的行为，如何保证不引发异常？

Question

I was reading this:

http://www.cplusplus.com/reference/cstdlib/atoi/

when I saw two sentences that make no sense to me towards the end.

this function never throws exceptions.

vs.

If str does not point to a valid C-string, or if the converted value would be out of the range of values representable by an int, it causes undefined behavior.

If the behavior of a bad parse is undefined, doesn't that mean all bets are off, and it's entirely possible for an exception to be raised? Or does this mean "undefined except that the runtime promises not to throw an exception"?

Answer 1

When the C or C++ standards speak of undefined behaviour, they mean that the consequence of running the program as a whole is undefined, not that the result or consequence of executing a particular construct is unspecified. It is even possible that execution of the program will be derailed before the erroneous construct is executed . For example, the runtime may detect that a pointer which will later be provided to atoi is invalid, and interrupt execution at that point. If the compiler could prove that this will happen, it could even fail to compile the program. The standard(s) explicitly make no restriction on what might be the result of the execution of a program which engenders undefined behaviour.

Having said that, it is unlikely that calling atoi with an invalid argument will raise an exception. The most likely consequences of integer overflow are truncation, clamping, or a trap/signal (which is not an exception); the most likely consequence of an invalid pointer is a segfault, which (on a Unix-like system) is a signal; as above, signals are not exceptions.

Nonetheless, it is not impossible that a given implementation may choose to raise an exception on receipt of a signal produced by a segfault or an integer overflow. Such an implementation would presumably attempt to ensure that an exception so raised could be caught, even if the signal is raised during execution of a function declared as not throwing. (Such an implementation would probably also document which exception would be raised in such cases, since an implementation is free to define the consequence of behaviour undefined by the standard.) If that attempt failed, and the exception was instead punted higher up the exception stack than was desired, that would still fall inside the complete lack of standard specification; the worst the implementation could be accused of would be failing to implement its own extension to the standard, which is a quality-of-implementation issue.

---

Language-lawyerly addition:

Obligatory standard quote: (§1.9 [intro.execution] , paragraph 5)

A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input. However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).

Any description of program execution made by the standard ("shall not throw exceptions", for example) needs to be interpreted within the context of that paragraph.

Answer 2

The C++ standard defines the term "undefined" to (in effect) mean that the C++ standard does not place any constraints on what happens.

A statement that a function does not throw exceptions means that the specification of the function does not include throwing any exceptions.

Yes, it is possible for an implementer (of a compiler or an implementation of the standard library) to throw an exception in a circumstance that is undefined according to the standard. After all, throwing an exception is a perfectly acceptable decision by an implementer if the standard does not constrain what is permitted to occur.

However, that does not mean instances of undefined behaviour must result in exceptions being thrown. Nor does it mean that a thrown exception indicates that some instance of undefined behaviour has occurred.

It does mean that two different implementations (eg different versions of some vendor's product, or products from different vendors) can do completely different things in response to an instance of undefined behaviour. One can throw an exception of some form. Another can reformat the systems hard drive (although, fortunately, implementations that deliberately do this are rare). Because the behaviour is undefined according to the standard, whatever happens is correct - at least according to the standard.

Answer 3

When it says that it does not throw an exception, you should read that - do not expect an exception to be raised when a problem arises.

Of course the exception may be raised by a pure luck, but it is very unlikely to happen. You shouldn't rely on it.

Answer 4

All guarantees about the function are only valid as long as you pass a valid pointer to a string.

If you don't, anything may happen, including throwing an exception.

In other words, the part about unspecified behavior takes priority over the part about the regular behavior.