fix out-of-range float to int conversion in to_nonnegative_int

[aizu-m]

The floating-point overload of detail::to_nonnegative_int casts value to Int before range-checking it, so the cast itself runs on out-of-range values.

Repro (header-only, clang -std=c++17 -fsanitize=undefined):

fmt::format("{:%j}", std::chrono::duration<double>(1e300));

include/fmt/chrono.h:937:37: runtime error: 1.15741e+295 is outside the range of representable values of type 'int'

Path: on_day_of_year -> write(days(), ...) -> to_nonnegative_int(days(), INT_MAX). Observation: static_cast<Int>(value) is evaluated first and the range check only sees the already-converted value, so the behaviour is undefined before the throw can happen.

Fix: do the range check first, comparing against static_cast<T>(upper) + 1. The + 1 matters at the float boundary: static_cast<float>(INT_MAX) rounds up to 2^31, so value > static_cast<T>(upper) would let a value equal to 2^31 through and the cast would still overflow. With >= upper + 1 both the comparison and the conversion are well defined.

Found while running the chrono formatters under UBSan. Added a regression test to chrono_test.out_of_range; all chrono tests pass.

[vitaut]

Please don't submit AI slop or you will be banned.

[aizu-m]

The description was my mistake — I pasted the writeup from a different patch entirely. I've fixed the PR body to describe the actual change.

The bug itself is real: fmt::format("{:%j}", std::chrono::duration<double>(1e300)) evaluates static_cast<int>(value) before the range check, and UBSan flags float-cast-overflow at chrono.h:937. Repro and trace are in the updated description. Happy to resubmit clean if you'd rather take it that way.

[vitaut]

Makes sense now, reopened.

[vitaut]

LGTM

[vitaut]

Merged, thanks!