Skip to content

ami: Fix ami_parse_bdf() discarding const from strchr() result#40

Open
amd-vserbu wants to merge 1 commit into
Xilinx:mainfrom
amd-vserbu:fix/no-discard-const
Open

ami: Fix ami_parse_bdf() discarding const from strchr() result#40
amd-vserbu wants to merge 1 commit into
Xilinx:mainfrom
amd-vserbu:fix/no-discard-const

Conversation

@amd-vserbu

Copy link
Copy Markdown
Contributor

Summary

ami_parse_bdf() stores the result of strchr() (called on a const char *) into a non-const char *. This discards the const qualifier. It was silently accepted on older toolchains but is a hard error when building in C23 mode against glibc ≥ 2.41 (e.g. GCC 15 / Ubuntu 26.04), where <string.h> provides the C23 const-correct strchr overloads. Since sw/AMI/api/Makefile builds with -Wall -Werror, the warning is fatal.

Change

-    char *c = NULL;
+    const char *c = NULL;

in sw/AMI/api/src/ami.c (ami_parse_bdf()). c only ever holds the strchr result and is used for a null check and the pointer subtraction (c - bdf); it is never used to mutate the string, so const char * is correct in all language modes.

Diagnostic (before)

ami.c:392:11: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  392 |         c = strchr(bdf, ':');
      |           ^
cc1: all warnings being treated as errors

Why now

glibc 2.41 added C23 const-correct overloads for strchr (returns const char * for a const char * argument). The same GCC 14 passes -std=gnu23 against glibc 2.39 but fails against glibc 2.43, so this is a glibc/standard-mode interaction, not a single GCC version. -std=gnu17 and earlier are unaffected.

Testing

Compiled sw/AMI/api with -Wall -Werror across GCC 11–15 and glibc 2.39 / 2.43, in default, -std=gnu17, and -std=gnu23 modes. The change compiles cleanly in every combination; the original code fails only under C23 + glibc ≥ 2.41.

Signed-off-by: Vlad-Gabriel Serbu <Vlad-Gabriel.Serbu@amd.com>
@amd-vserbu

Copy link
Copy Markdown
Contributor Author

This addresses issue #39

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.

1 participant