Undefined behavior adding 1 to nullptr

[no-more-secrets]

On master I am seeing some UB here:

../fmt/include/fmt/core.h:2485:13: runtime error: applying non-zero offset 1 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../fmt/include/fmt/core.h:2485:13 in

which is this line:

if (begin + 1 < end && begin[1] == '}' && is_ascii_letter(*begin) &&
      *begin != 'L') {

when begin is nullptr. But in that case it should be the case that end is nullptr as well, and so we can get around this by only adding 1 to begin when begin != end, which logically makes sense anyway, since if begin == end then begin + 1 < end will always be false anyway. That seems to prevent the begin + 1 from executing when begin == nullptr. I will send a PR for this.

[vitaut]

Please provide a self-contained example (preferably in godbolt) that demonstrates the UB.

[no-more-secrets]

@vitaut Here is a minimal reproducer: https://godbolt.org/z/KTYd95o1W

When I change dynamic_formatter<> to formatter<std::string> then the issue goes away, so it could be specific to dynamic_formatter.

[no-more-secrets]

As an aside, I am using dynamic_formatter because in my real code the formatter in question is for a std::variant, and so I lifted the example from the comments in format.h. But now I am curious, why should we use dynamic_formatter in that situation as opposed to the regular formatter?

Also note that this is likely a recent regression because the code in question in my code base is pretty old, and I encountered this error in the process of upgrading from 7.3.1 to 8.0.1 today.

[vitaut]

Fixed in 659de77, thanks for reporting.

why should we use dynamic_formatter in that situation as opposed to the regular formatter?

dynamic_formatter parses format specs at runtime when the information of an alternative stored in a variant is available.