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"?
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.
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.