RTEMS | x86_64 BSPs: unterminated string initializer warnings (#5329)

[Joel Sherrill (@joel)]

Joel Sherrill created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5329



## Summary

The ACPI code in bsps/shared appears to be only be used in x86_64 BSPs. There are at least two tables which have a 4 character array which gets a 4 character plus NUL for a total of five characters. This generates this type of warning for each element in the array of structures when _-Wunterminated-string-initialization_ is enabled. 

`../../../bsps/shared/acpi/acpica/namespace/nsrepair.c:215:7: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (5 chars into 4 available) [-Wunterminated-string-initialization]`

I tracked through one use of the string element and in that case _strncmp()_ with a length of 4 was used. This warning appears to be an intentional and safe use. GCC's documentation has this:

> Warn about character arrays initialized as unterminated character sequences with a string literal, unless the declaration being initialized has the nonstring attribute. For example:
> 
>     char arr[3] = "foo"; /* Warning.  */
>     char arr2[3] __attribute__((nonstring)) = "bar"; /* No warning.  */
> 
> warning is enabled by -Wextra. If -Wc++-compat is enabled, the warning has slightly different wording and warns even if the declaration being initialized has the nonstring warning, as in C++ such initializations are an error.

Adding the nonstring attribute to the definition of ACPI_NAME_INFO.Name in bsps/include/acpi/acpica/aclocal.h is likely to be the correct solution.

The fix should be simple once proper use is confirmed. Since the code is third party, this will need to be in an ifdef __rtems__ section and RTEMS_NON_STRING may need to be added to basedefs.h.

## Steps to reproduce
Add  _-Wunterminated-string-initialization_ to optwarn.yml.

### Pre-set options

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5329
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250904/c8daca9e/attachment.htm>