klibc - Jul 2025 - [PATCH 1/2] mount_opts: Fix the mount_opts str length

Newer versions of LLVM report:

usr/utils/mount_opts.c:20:3: error: initializer-string for character array is
too long, array size is 8 but initializer has size 9 (including the null
terminating character); did you mean to use the 'nonstring' attribute?
[-Werror,-Wunterminated-string-initialization]
   20 |         {"diratime", MS_NODIRATIME, 0, MS_NODIRATIME},
      |          ^~~~~~~~~~

This is indeed a bit odd. "diratime" is 9 bytes long with the \0
terminator but placed into a struct that uses a static length of 8 bytes
for that buffer. I suppose this can cause all sorts of undefined
behaviors in theory but that in practice this never caused anything bad
because the next field is an unsigned long containing 2048 so the upper
bytes are 0 and act as string terminators by chance.

Anyway, fixing this helps unblock builds with newer toolchains.

Signed-off-by: Florent Revest <revest at chromium.org>
---
 usr/utils/mount_opts.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/usr/utils/mount_opts.h b/usr/utils/mount_opts.h
index cf47cae8..5195c88a 100644
--- a/usr/utils/mount_opts.h
+++ b/usr/utils/mount_opts.h
@@ -2,7 +2,7 @@
 #define UTILS_MOUNT_OPTS_H
 
 struct mount_opts {
-	const char str[8];
+	const char str[9];
 	unsigned long rwmask;
 	unsigned long rwset;
 	unsigned long rwnoset;
-- 
2.50.0.727.gbf7dc18ff4-goog

When building with recent versions of LLVM, I get the following errors:

usr/include/bits64/bitsize/stdint.h:27:9: error: '__INT64_C' macro
redefined [-Werror,-Wmacro-redefined]
   27 | #define __INT64_C(c)  c ## L
      |         ^
<built-in>:194:9: note: previous definition is here
  194 | #define __INT64_C(c) c##L
      |         ^

It looks like newer versions of LLVM also define these macros.
Surrounding them with ifndef avoids errors.

Signed-off-by: Florent Revest <revest at chromium.org>
---
 usr/include/bits64/bitsize/stdint.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/usr/include/bits64/bitsize/stdint.h
b/usr/include/bits64/bitsize/stdint.h
index 988e6396..a28c041e 100644
--- a/usr/include/bits64/bitsize/stdint.h
+++ b/usr/include/bits64/bitsize/stdint.h
@@ -24,8 +24,12 @@ typedef unsigned long int	uint_fast32_t;
 typedef long int		intptr_t;
 typedef unsigned long int	uintptr_t;
 
+#ifndef __INT64_C
 #define __INT64_C(c)  c ## L
+#endif
+#ifndef __UINT64_C
 #define __UINT64_C(c) c ## UL
+#endif
 
 #define __PRI64_RANK	"l"
 #define __PRIFAST_RANK  "l"
-- 
2.50.0.727.gbf7dc18ff4-goog

On Thu, 2025-07-10 at 19:39 +0200, Florent Revest wrote:
> Newer versions of LLVM report:
> 
> usr/utils/mount_opts.c:20:3: error: initializer-string for character array
is too long, array size is 8 but initializer has size 9 (including the null
terminating character); did you mean to use the 'nonstring' attribute?
[-Werror,-Wunterminated-string-initialization]
>    20 |         {"diratime", MS_NODIRATIME, 0, MS_NODIRATIME},
>       |          ^~~~~~~~~~
> 
> This is indeed a bit odd. "diratime" is 9 bytes long with the \0
> terminator but placed into a struct that uses a static length of 8 bytes
> for that buffer. I suppose this can cause all sorts of undefined
> behaviors in theory but that in practice this never caused anything bad
> because the next field is an unsigned long containing 2048 so the upper
> bytes are 0 and act as string terminators by chance.
[...]

Applied, thanks.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
                                                    - Carolyn Scheppner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.zytor.com/archives/klibc/attachments/20250712/dd7f5469/attachment.sig>