-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/usr/include/string.h bad basename() prototype #46959
Comments
?? |
Yeah, that's likely wrong. It was just what "xlocate /usr/include/string.h" gave, and the form had package as a mandatory field. |
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 |
So, we move |
It would be The idea in musl, is that they declare it using k&r style in The proper workaround here would be smth like:
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) |
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. |
This issue was fixed upstream: bminor/musl@725e17e |
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
The text was updated successfully, but these errors were encountered: