Skip to content

Don't use __builtin_strlen #4423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brevzin opened this issue Apr 21, 2025 · 1 comment · Fixed by #4429
Closed

Don't use __builtin_strlen #4423

brevzin opened this issue Apr 21, 2025 · 1 comment · Fixed by #4429

Comments

@brevzin
Copy link
Contributor

brevzin commented Apr 21, 2025

When upgrading {fmt}, b4d1d7f8e broke some of our usage. We had a place where we were building up a format string using a type like this:

template <size_t N>
struct fixed_string {
    char data[N] = {}; 

    constexpr fixed_string(char const (&m)[N]) {
        for (size_t i = 0; i != N; ++i) {
            data[i] = m[i];
        }
    }   
};

And trying to do something like:

static constexpr auto f = fixed_string("x={}");
fmt::print(f.data, 42);

This works on fmt 10.2.1 and 11.0, fails on trunk — after that commit, with:

/opt/compiler-explorer/libs/fmt/trunk/include/fmt/base.h:543:31: error: '__builtin_strlen(((const char*)(& f.fixed_string<5>::data)))' is not a constant expression
  543 |       size_ = __builtin_strlen(detail::narrow(s));
      |               ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

gcc says that __builtin_strlen isn't usable like this. Which... if they say so. But seems unlikely this will change, so I think {fmt} should also revert to previous usage.

@vitaut
Copy link
Contributor

vitaut commented Apr 21, 2025

That's unfortunate but I agree that we shouldn't break this reasonable usage. A PR to revert and add a test case would be welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants