/usr/include/string.h bad basename() prototype

[cazfi]

Is this a new report?

Yes

System Info

Void 6.5.8_1 x86_64-musl

Package(s) Affected

glibc-devel-2.36_2

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

Compiling code that calls basename() works when compiler on C23 mode.

Actual behaviour

When compiling code that calls basename(char *) under C23 mode, the compile fails as the prototype on /usr/include/string.h does not have any parameters listed.

Steps to reproduce

1. Have code calling basename() with a proper parameter.
2. Compile it with gcc-13 and -std=c2x

[sgn]

Void 6.5.8_1 x86_64-musl
Package(s) Affected

glibc-devel-2.36_2

??

[cazfi]

Yeah, that's likely wrong. It was just what "xlocate /usr/include/string.h" gave, and the form had package as a mandatory field.

[classabbyamp]

musl (even current git HEAD) doesn't fully support C23 yet, I think

https://inbox.vuxu.org/musl/6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com/t/#u

[sgn]

The reason for the non-prototype declaration is explained in commit
37bb3cce4598c19288628e675eaf1cda6e96958f:

    omit declaration of basename wrongly interpreted as prototype in C++

    the non-prototype declaration of basename in string.h is an ugly
    compromise to avoid breaking 2 types of broken software:

    1. programs which assume basename is declared in string.h and thus
    would suffer from dangerous pointer-truncation if an implicit
    declaration were used.

    2. programs which include string.h with _GNU_SOURCE defined but then
    declare their own prototype for basename using the incorrect GNU
    signature for the function (which would clash with a correct
    prototype).

So, we move basename to #ifdef __cplusplus?

[oreo639]

So, we move basename to #ifdef __cplusplus?

It would be #ifndef, which is already the case and also not specifically the issue here.
The issue here is that C23 removed support for the original pre-ANSI k&r style function declarations/definitions and int func() was made from meaning an old k&r style declaration to being equivalent to int func(void) just like how it has been in C++.

The idea in musl, is that they declare it using k&r style in string.h so that it would be available for glibc compatibility while not breaking applications that re-declare basename(), while having the proper definition in libgen.h. In C17, this is fine. In C23, they become conflicting declarations.

The proper workaround here would be smth like:

#if !defined(__cplusplus) && !(defined(__STDC_VERSION__) && __STDC_VERSION__ > 201710L)
char *basename();
#endif

Although this should probably be dealt with upstream before we patch it. (and the final C23 standard will not be submitted for publication until earlier next year)
https://en.cppreference.com/w/c/language/function_declaration

[ahesford]

Given that our currently shipping compiler and musl version don't claim to support (this part of) C23, this seems like expected behavior rather than an actionable bug report.

[oreo639]

This issue was fixed upstream: bminor/musl@725e17e
The patch has been imported to: #45500