From: oreo639 <oreo639@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: /usr/include/string.h bad basename() prototype
Date: Tue, 31 Oct 2023 06:34:47 +0100 [thread overview]
Message-ID: <20231031053447.J-8qdzZovuSSuBJAXSAXO6el_zHCgD_W4mbxhK-SEco@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-46959@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
New comment by oreo639 on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786455944
Comment:
> So, we move `basename` to `#ifdef __cplusplus`?
It would be `#ifndef`, which is already the case and also not the issue in this case.
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 published until earlier next year)
next prev parent reply other threads:[~2023-10-31 5:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-29 18:47 [ISSUE] " cazfi
2023-10-30 1:08 ` sgn
2023-10-30 6:27 ` cazfi
2023-10-31 2:50 ` classabbyamp
2023-10-31 2:51 ` classabbyamp
2023-10-31 2:51 ` classabbyamp
2023-10-31 2:52 ` classabbyamp
2023-10-31 2:53 ` classabbyamp
2023-10-31 4:21 ` sgn
2023-10-31 5:09 ` oreo639
2023-10-31 5:10 ` oreo639
2023-10-31 5:10 ` oreo639
2023-10-31 5:11 ` oreo639
2023-10-31 5:12 ` oreo639
2023-10-31 5:14 ` oreo639
2023-10-31 5:15 ` oreo639
2023-10-31 5:16 ` oreo639
2023-10-31 5:18 ` oreo639
2023-10-31 5:18 ` oreo639
2023-10-31 5:19 ` oreo639
2023-10-31 5:20 ` oreo639
2023-10-31 5:23 ` oreo639
2023-10-31 5:24 ` oreo639
2023-10-31 5:24 ` oreo639
2023-10-31 5:26 ` oreo639
2023-10-31 5:26 ` oreo639
2023-10-31 5:27 ` oreo639
2023-10-31 5:29 ` oreo639
2023-10-31 5:31 ` oreo639
2023-10-31 5:31 ` oreo639
2023-10-31 5:34 ` oreo639 [this message]
2023-10-31 5:35 ` oreo639
2023-10-31 5:37 ` oreo639
2023-10-31 5:44 ` oreo639
2023-12-03 1:12 ` [ISSUE] [CLOSED] " ahesford
2023-12-03 1:12 ` ahesford
2024-01-22 21:47 ` oreo639
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231031053447.J-8qdzZovuSSuBJAXSAXO6el_zHCgD_W4mbxhK-SEco@z \
--to=oreo639@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).