Menu ▾ ▴

libpfm4 Merge Request #39: Fix discarded const qualifier build failures in pfmlib_common.c and tests/validate_x86.c (open)

Merging...

Merged

Something went wrong. Please, merge manually

Checking if merge is possible...

Something went wrong. Please, merge manually

Frank Heimes wants to merge 2 commits from /u/fheimes/perfmon2/ to master, 2026-07-21

Two latent type bugs in generic, architecture-independent code cause
build failures on toolchains where the C library declares functions
such as strpbrk(3)/strchr(3) so that they propagate the constness of
their first argument to the return type -- glibc does this deliberately
to catch exactly this kind of mistake, e.g. since glibc 2.43.

Found while preparing a hardware-enablement update (adding IBM z17
CPU-MF counter support) for Ubuntu, where the very latest development
toolchain surfaced both issues and aborted the build outright:

pfmlib_common.c: In function 'pfmlib_parse_event':
pfmlib_common.c:1896:11: error: assignment discards 'const'
qualifier from pointer target type [-Werror=discarded-qualifiers]
 1896 |         p = strpbrk(event, PFMLIB_EVENT_DELIM);
      |           ^

validate_x86.c: In function 'check_pmu_supported':
validate_x86.c:10518:11: error: assignment discards 'const'
qualifier from pointer target type [-Werror=discarded-qualifiers]
10518 |         p = strchr(evt, ':');
      |           ^

Neither issue is specific to any patch or feature; they exist on
current master and are hit purely by the toolchain change, on every
architecture.

Two commits, one per occurrence, both pure type-correctness fixes
with no change in behaviour:

  1. pfmlib_parse_event() (lib/pfmlib_common.c): "p" was only ever
    tested for truthiness right after the strpbrk() call, then
    unconditionally reassigned afterwards for its later, legitimately
    mutable use. Drop the pointless assignment and test the return
    value of strpbrk() directly instead.

  2. check_pmu_supported() (tests/validate_x86.c): "p" is used
    afterwards, but strictly for reading (a dereference and pointer
    arithmetic), never written through. Declare it "const char *" to
    match its actual use.

Verified with a full "make -k" build of lib/, tests/, examples/ and
perf_examples/ (0 remaining errors, previously aborted on the first
error above), and a full run of ./tests/validate (1547 x86 events,
0 errors, all tests passed) on top of current master.

Signed-off-by: Frank Heimes frank.heimes@canonical.com

Source branch: fix-strpbrk-const-discard (in fork /u/fheimes/perfmon2/)
Target: perfmon2/libpfm4:master

AI assisted generated, but human verified and tested (incl. test build)

Commit Date  
[489210] (fix-strpbrk-const-discard) by Frank Heimes Frank Heimes

tests/validate_x86: fix assignment discarding const qualifier

check_pmu_supported() receives "evt" as "const char *", but stores the
result of strchr(evt, ':') into "p", which is declared as plain
"char *":

char *p;
...
p = strchr(evt, ':');
if (!p)
return 1;
if (*(p+1) != ':')
return 1;
...
if (!strncmp(info.name, evt, p - evt))

Unlike lib/pfmlib_common.c's pfmlib_parse_event() (fixed in the
previous commit), "p" here is genuinely used afterwards, but strictly
for reading: a dereference (*(p+1)) and pointer arithmetic (p - evt).
It is never written through, and never reassigned to point elsewhere
in this function.

On toolchains where the C library declares strchr(3) such that it
propagates the constness of its first argument to the return type
(glibc does this to catch exactly this kind of mistake, e.g. since
glibc 2.43), this line trips -Werror=discarded-qualifiers:

validate_x86.c: In function 'check_pmu_supported':
validate_x86.c:10518:11: error: assignment discards 'const'
qualifier from pointer target type [-Werror=discarded-qualifiers]
10518 | p = strchr(evt, ':');
| ^

This only becomes visible once the equivalent issue in
lib/pfmlib_common.c is fixed, since the build previously aborted
before ever reaching tests/.

Fix it by declaring "p" as "const char *", matching its read-only use
in this function. Pure type-correctness fix, no change in behaviour.

Verified with a full "make -k" build of lib/, tests/, examples/ and
perf_examples/ (0 remaining errors), and a full run of
./tests/validate (1547 x86 events, 0 errors, all tests passed).

Signed-off-by: Frank Heimes <frank.heimes@...>

 2026-07-21 08:28:10 Tree
[9fe14a] by Frank Heimes Frank Heimes

pfmlib_parse_event: fix assignment discarding const qualifier

pfmlib_parse_event() receives "event" as "const char *", but stores
the result of strpbrk(event, PFMLIB_EVENT_DELIM) into the function-wide
scratch variable "p", which is declared as plain "char *":

char *str, *s, *p;
...
p = strpbrk(event, PFMLIB_EVENT_DELIM);
if (p)
return PFM_ERR_INVAL;

"p" is only tested for truthiness here; it is unconditionally
reassigned right afterwards for its later, legitimately mutable, use
on the strdup()'ed copy of the string. So this particular assignment
serves no purpose beyond the boolean check, and can simply be dropped.

On toolchains where the C library declares strpbrk(3) such that it
propagates the constness of its first argument to the return type
(glibc does this to catch exactly this kind of mistake, e.g. since
glibc 2.43), this line trips -Werror=discarded-qualifiers and aborts
the build on every architecture, since this is generic,
architecture-independent code:

pfmlib_common.c: In function 'pfmlib_parse_event':
pfmlib_common.c:1896:11: error: assignment discards 'const'
qualifier from pointer target type [-Werror=discarded-qualifiers]
1896 | p = strpbrk(event, PFMLIB_EVENT_DELIM);
| ^

Fix it by testing the return value of strpbrk() directly, without
assigning it to "p" at all. Pure type-correctness fix, no change in
behaviour: "p" continues to be assigned and used exactly as before
for the rest of the function.

Signed-off-by: Frank Heimes <frank.heimes@...>

 2026-07-21 08:26:50 Tree

Discussion

Log in to post a comment.

Auth0 Logo