Unspecified Behavior in Multi-Digit Optimizations

[Alexhuszagh]

I've noticed a similar issue in fast-float-rust, where checking the bounds of the array produces undefined behavior (in Rust), and similar behavior (unspecified) exists in fast_float.

Quoting the C++14 standard:

If two pointers p and q of the same type point to different objects that are not members of the same object or elements of the same array or to different functions, or if only one of them is null, the results of p<q, p>q, p<=q, and p>=q are unspecified.

Therefore, the following code is unspecified behavior (according to cppreference, it is undefined behavior, however, I am not a language lawyer, so I am unsure of the true semantics).

fast_float/include/fast_float/ascii_number.h

Lines 118 to 123 in fe1ce58

	if ((p + 8 <= pend) && is_made_of_eight_digits_fast(p)) {
	i = i * 100000000 + parse_eight_digits_unrolled(p); // in rare cases, this will overflow, but that's ok
	p += 8;
	if ((p + 8 <= pend) && is_made_of_eight_digits_fast(p)) {
	i = i * 100000000 + parse_eight_digits_unrolled(p); // in rare cases, this will overflow, but that's ok
	p += 8;

Specifically, since pend is one-past-the-end of the array, the last valid point of comparison, the compiler could optimize this as always being true, since p + 8 <= pend must always be true, an undesirable outcome.

The compliant solution is as follows:

#include <iterator>
...

  if ((std::distance(p, pend) >= 8) && is_made_of_eight_digits_fast(p)) {
    i = i * 100000000 + parse_eight_digits_unrolled(p); // in rare cases, this will overflow, but that's ok
    p += 8;
    if ((std::distance(p, pend) >= 8) && is_made_of_eight_digits_fast(p)) {
      i = i * 100000000 + parse_eight_digits_unrolled(p); // in rare cases, this will overflow, but that's ok
      p += 8;
    }
  }

Another example in parse_decimal also needs to be patched.

[lemire]

Yes. You are correct, this is (technically) undefined behaviour. Thanks for pointing it out.

[lemire]

I expect that your fix is correct.