[libc++] Fix the locale base API on Linux with musl

[reactive-firewall]

Patch Notes

Details

[libc++] - minor refactor - Handle the same guards used by musl libc to conditionally compile the 'Strtonum functions'.

• Closes GHI configurations for Strtonum functions in libcxx are partial/incomplete when '_LIBCPP_HAS_MUSL_LIBC' is defined. #167977

Affected Versions

• llvm-project: Versions <= 21.1.5 (other versions may also be impacted)
• Platforms: Primarily Linux with musl's libc
• Subprojects: libcxxabi, libcxx

---

Context

This pull request addresses an issue encountered when building libcxx with certain configurations (-D_LIBCPP_HAS_MUSL_LIBC & -D__linux__) that lack the _GNU_SOURCE definition. Specifically, this issue arises if the system musl libc is built with _BSD_SOURCE instead of _GNU_SOURCE. The resultant configuration leads to problems with the "Strtonum functions" in the file libcxx/include/__locale_dir/support/linux.h, affecting the following functions:

• __strtof
• __strtod
• __strtold

Error messages displayed include:

error: no member named 'strtof_l' in the global namespace

error: no member named 'strtod_l' in the global namespace

error: no member named 'strtold_l' in the global namespace

For more insight, relevant code can be accessed here.

---

Suggested Fix

The resolution involves implementing conditional compilation guards that align with those utilized by musl libc. This is in line with existing practices for functions like __strtoll and __strtoull, as seen in libcxx/include/__locale_dir/support/linux.h. The proposed changes to the functions are outlined below:

  //
  // Strtonum functions
  //
  inline _LIBCPP_HIDE_FROM_ABI float __strtof(const char* __nptr, char** __endptr, __locale_t __loc) {
+ #if !_LIBCPP_HAS_MUSL_LIBC || defined(_GNU_SOURCE)
    return ::strtof_l(__nptr, __endptr, __loc);
+ #else
+   (void)__loc;
+   return ::strtof(__nptr, __endptr);
+ #endif
  }

  inline _LIBCPP_HIDE_FROM_ABI double __strtod(const char* __nptr, char** __endptr, __locale_t __loc) {
+ #if !_LIBCPP_HAS_MUSL_LIBC || defined(_GNU_SOURCE)
    return ::strtod_l(__nptr, __endptr, __loc);
+ #else
+   (void)__loc;
+   return ::strtod(__nptr, __endptr);
+ #endif
  }

  inline _LIBCPP_HIDE_FROM_ABI long double __strtold(const char* __nptr, char** __endptr, __locale_t __loc) {
+ #if !_LIBCPP_HAS_MUSL_LIBC || defined(_GNU_SOURCE)
    return ::strtod_l(__nptr, __endptr, __loc);
+ #else
+   (void)__loc;
+   return ::strtold(__nptr, __endptr);
+ #endif
  }

Note

The musl development team may consider it a defect not to check for defined(_GNU_SOURCE). However, given the musl implementation (version circa v1.2.5), it discards the __loc argument even if defined(_GNU_SOURCE) is present, while omitting strto*_l functions entirely without it. Therefore, an optimized approach might be to omit the || defined(_GNU_SOURCE) condition, as it currently holds no effect unless musl's implementation changes in future versions.
However this implementation has opted for 'correctness' in defined behavior. This should help ensure no regression is introduced for other configurations.

---

References / See Also

For further investigation, see additional details in GHI #167977

---

cc: @ldionne (Please Review)

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Mr. Walls (reactive-firewall)

Changes

Handle the same guards used by musl libc to conditionally compile the 'Strtonum functions'

See GHI llvm/llvm-project#167977

---

cc: @ldionne (Please Review)

---

Full diff: https://github.com/llvm/llvm-project/pull/167980.diff

1 Files Affected:

• (modified) libcxx/include/__locale_dir/support/linux.h (+15)

diff --git a/libcxx/include/__locale_dir/support/linux.h b/libcxx/include/__locale_dir/support/linux.h
index 94a2ecb9a940d..2233c12b7af8b 100644
--- a/libcxx/include/__locale_dir/support/linux.h
+++ b/libcxx/include/__locale_dir/support/linux.h
@@ -83,15 +83,30 @@ inline _LIBCPP_HIDE_FROM_ABI __lconv_t* __localeconv(__locale_t& __loc) {
 // Strtonum functions
 //
 inline _LIBCPP_HIDE_FROM_ABI float __strtof(const char* __nptr, char** __endptr, __locale_t __loc) {
+#if !_LIBCPP_HAS_MUSL_LIBC || defined(_GNU_SOURCE)
   return ::strtof_l(__nptr, __endptr, __loc);
+#else
+  (void)__loc;
+  return ::strtof(__nptr, __endptr);
+#endif
 }
 
 inline _LIBCPP_HIDE_FROM_ABI double __strtod(const char* __nptr, char** __endptr, __locale_t __loc) {
+#if !_LIBCPP_HAS_MUSL_LIBC || defined(_GNU_SOURCE)
   return ::strtod_l(__nptr, __endptr, __loc);
+#else
+  (void)__loc;
+  return ::strtod(__nptr, __endptr);
+#endif
 }
 
 inline _LIBCPP_HIDE_FROM_ABI long double __strtold(const char* __nptr, char** __endptr, __locale_t __loc) {
+#if !_LIBCPP_HAS_MUSL_LIBC || defined(_GNU_SOURCE)
   return ::strtold_l(__nptr, __endptr, __loc);
+#else
+  (void)__loc;
+  return ::strtold(__nptr, __endptr);
+#endif
 }
 
 inline _LIBCPP_HIDE_FROM_ABI long long __strtoll(const char* __nptr, char** __endptr, int __base, __locale_t __loc) {

[reactive-firewall]

If accepted, Please Merge on my behalf (as I do not have write access)

Thanks in advance

[github-actions]

⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo.
Please turn off Keep my email addresses private setting in your account.
See LLVM Developer Policy and LLVM Discourse for more information.

[frederick-vs-ja]

Could you make the title and description of this PR (which are generally used as squashed commit message) more descriptive?

[reactive-firewall]

Could you make the title and description of this PR (which are generally used as squashed commit message) more descriptive?

PR Title, and description have been updated. Hopefully this helps.

---

If accepted, Please Merge on my behalf. - Thanks in advance.