Skip to content

clang > 20.1.4 compat: unterminated strings #584

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Lukasdoe
Copy link

clang introduced a new warning (following gcc) for string initialization to char arrays that do not fit the null terminal.

Introduced here: llvm/llvm-project#137829
Included in LLVM version LLVM 20.1.4+

More detail:
-Wunterminated-string-initialization warns for c string literals that are written to a buffer too small to include a null terminator. This warning is also included in -Wextra which is enabled for wasi-libc and fails compilation due to -Werror.

Possible fixes:

  1. deactivate the warning
  2. add __attribute__ ((nonstring)) to the three occurrences where this is a problem.

Chosen solution: 1.
Since the attribute is not available on older clang versions, it would trigger another warning there.

(included a small formatting change in the commit - pls ignore)

-Wunterminated-string-initialization warns for c string literals that are written to a buffer too small to include a null terminator. This warning is also included in -Wextra which is enabled for wasi-libc and fails compilation due to -Werror.
@yamt
Copy link
Contributor

yamt commented May 26, 2025

Since the attribute is not available on older clang versions, it would trigger another warning there.

have you considered __has_attribute?

@Lukasdoe
Copy link
Author

I did not! However, applying the __has_attribute macro would introduce an ifdef, cluttering the code. Idk what is best in this situation tbh, since it's only 3 sites in the entire project that trigger the warning. What would you suggest ist a cleaner solution?

@yamt
Copy link
Contributor

yamt commented May 27, 2025

the three occurrences where this is a problem.

for those who wonder where they are:

libc-top-half/musl/src/stdio/vfprintf.c:170:2: warning: initializer-string for character array is too long, array size is 16 but initializer has size 17 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization]
  170 |         "0123456789ABCDEF"
      |         ^~~~~~~~~~~~~~~~~~
libc-top-half/musl/src/locale/pleval.c:90:31: warning: initializer-string for character array is too long, array size is 11 but initializer has size 12 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization]
   90 |         static const char opch[11] = "|&=!><+-*%/";
      |                                      ^~~~~~~~~~~~~
libc-top-half/musl/src/locale/pleval.c:91:31: warning: initializer-string for character array is too long, array size is 6 but initializer has size 7 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization]
   91 |         static const char opch2[6] = "|&====";
      |                                      ^~~~~~~~

@sbc100
Copy link
Member

sbc100 commented May 27, 2025

Hmm.. I wonder if we should be compiling musl with -Wextra -Werror at all? I suppose the list of exception is manageable right now but if it starts to grow we should probably just drop the -Wextra since its not something that upstream musl builds with.

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

Successfully merging this pull request may close these issues.

3 participants