A simple fix is using unsigned integers, as unsigned overflow is well-defined.
(There isn't a way in C/C++ to request an exception or fault on integer overflow, which is what you'd want here, since you're running inside Python. A better conceptual fix is just doing the addition in Python, which is a more robust language than C/C++ for signed integer addition, but that kind of defeats the point of the example.)
GCC/Clang/VC++ represent 99% of the compiler market. In the exceedingly rare chance your vendor doesn't implement those extensions, you're probably a big enough customer of theirs that you can request it.
I mean, yes, I'm sympathetic to the argument that most people should use a variant of C that isn't actually C and is much better about undefined behavior (not just integer overflow but other things too). https://blog.regehr.org/archives/1180 has some thoughts along these lines.
I'm not sure that pybind11 wants to have its docs using a nonstandard variant of C, though, for lots of reasons, including that I expect the major use case of pybind11 is binding to existing C or C++ projects which are generally written in standard C or C++. (But not always! Postgres, for instance, is written in a variant of C with -fwrapv - not even -ftrapv, but a definition of signed overflow - instead of standard C.)
> Postgres, for instance, is written in a variant of C with -fwrapv - not even -ftrapv, but a definition of signed overflow - instead of standard C.
To my knowledge that's solely because historically there's been signed integer overflow checks that relied on signed overflow semantics, not because there's otherwise use of overflows. At some point we didn't have a nice, portable and fast way to do overflow checks and so -fwrapv was added... I'd like to revisit that.
