* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
@ 2023-10-30 1:08 ` sgn
2023-10-30 6:27 ` cazfi
` (34 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: sgn @ 2023-10-30 1:08 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 221 bytes --]
New comment by sgn on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1784324482
Comment:
```
Void 6.5.8_1 x86_64-musl
Package(s) Affected
glibc-devel-2.36_2
```
??
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
2023-10-30 1:08 ` sgn
@ 2023-10-30 6:27 ` cazfi
2023-10-31 2:50 ` classabbyamp
` (33 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: cazfi @ 2023-10-30 6:27 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
New comment by cazfi on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1784557012
Comment:
Yeah, that's likely wrong. It was just what "xlocate /usr/include/string.h" gave, and the form had package as a mandatory field.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype 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
` (32 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: classabbyamp @ 2023-10-31 2:50 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
New comment by classabbyamp on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786354670
Comment:
https://inbox.vuxu.org/musl/6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com/T/#u
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (2 preceding siblings ...)
2023-10-31 2:50 ` classabbyamp
@ 2023-10-31 2:51 ` classabbyamp
2023-10-31 2:51 ` classabbyamp
` (31 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: classabbyamp @ 2023-10-31 2:51 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
New comment by classabbyamp on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786354670
Comment:
musl (even current git HEAD) doesn't support C23 yet, I think
https://inbox.vuxu.org/musl/6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com/T/#u
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (3 preceding siblings ...)
2023-10-31 2:51 ` classabbyamp
@ 2023-10-31 2:51 ` classabbyamp
2023-10-31 2:52 ` classabbyamp
` (30 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: classabbyamp @ 2023-10-31 2:51 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
New comment by classabbyamp on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786354670
Comment:
musl (even current git HEAD) doesn't support C23 yet, I think
https://inbox.vuxu.org/musl/6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com/t/#u
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (4 preceding siblings ...)
2023-10-31 2:51 ` classabbyamp
@ 2023-10-31 2:52 ` classabbyamp
2023-10-31 2:53 ` classabbyamp
` (29 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: classabbyamp @ 2023-10-31 2:52 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
New comment by classabbyamp on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786354670
Comment:
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (5 preceding siblings ...)
2023-10-31 2:52 ` classabbyamp
@ 2023-10-31 2:53 ` classabbyamp
2023-10-31 4:21 ` sgn
` (28 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: classabbyamp @ 2023-10-31 2:53 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
New comment by classabbyamp on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786354670
Comment:
musl (even [current git HEAD](https://git.musl-libc.org/cgit/musl/tree/include/string.h#n99)) doesn't fully support C23 yet, I think
https://inbox.vuxu.org/musl/6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com/t/#u
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (6 preceding siblings ...)
2023-10-31 2:53 ` classabbyamp
@ 2023-10-31 4:21 ` sgn
2023-10-31 5:09 ` oreo639
` (27 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: sgn @ 2023-10-31 4:21 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
New comment by sgn on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1786419379
Comment:
```
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`?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (7 preceding siblings ...)
2023-10-31 4:21 ` sgn
@ 2023-10-31 5:09 ` oreo639
2023-10-31 5:10 ` oreo639
` (26 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:09 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 407 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`?
That is already the case, the issue here is that C23 removed support for the original k&r style and `int func()` was made from meaning an old k&r declaration to being equivalent to `int func(void)` same as C++.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (8 preceding siblings ...)
2023-10-31 5:09 ` oreo639
@ 2023-10-31 5:10 ` oreo639
2023-10-31 5:10 ` oreo639
` (25 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:10 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 413 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`?
That is already the case, the issue here is that C23 removed support for the original k&r style and `int func()` was made from meaning an old k&r style declaration to being equivalent to `int func(void)` same as C++.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (9 preceding siblings ...)
2023-10-31 5:10 ` oreo639
@ 2023-10-31 5:10 ` oreo639
2023-10-31 5:11 ` oreo639
` (24 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:10 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 422 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`?
That is already the case, the issue here is that C23 removed support for the original pre-ANSI k&r style and `int func()` was made from meaning an old k&r style declaration to being equivalent to `int func(void)` same as C++.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (10 preceding siblings ...)
2023-10-31 5:10 ` oreo639
@ 2023-10-31 5:11 ` oreo639
2023-10-31 5:12 ` oreo639
` (23 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:11 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 456 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`?
That is already the 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)` same as C++.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (11 preceding siblings ...)
2023-10-31 5:11 ` oreo639
@ 2023-10-31 5:12 ` oreo639
2023-10-31 5:14 ` oreo639
` (22 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:12 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 457 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`?
That is already the 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)` same as C++.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (12 preceding siblings ...)
2023-10-31 5:12 ` oreo639
@ 2023-10-31 5:14 ` oreo639
2023-10-31 5:15 ` oreo639
` (21 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:14 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 697 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`?
That is already the 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)` same as 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`
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (13 preceding siblings ...)
2023-10-31 5:14 ` oreo639
@ 2023-10-31 5:15 ` oreo639
2023-10-31 5:16 ` oreo639
` (20 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:15 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 802 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`?
That is already the 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)` same as 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`.
The proper workaround here would be to `#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L`.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (14 preceding siblings ...)
2023-10-31 5:15 ` oreo639
@ 2023-10-31 5:16 ` oreo639
2023-10-31 5:18 ` oreo639
` (19 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:16 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 994 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`?
That is already the 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)` same as 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`.
The proper workaround here would be to `#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L`.
Although this should probably be dealt with upstream before we patch it and as stated musl doesn't support C23 atm. (and the final C23 standard will not be published until earlier next year)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (15 preceding siblings ...)
2023-10-31 5:16 ` oreo639
@ 2023-10-31 5:18 ` oreo639
2023-10-31 5:18 ` oreo639
` (18 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:18 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1037 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 not this issue.
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)` same as 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`.
The proper workaround here would be to `#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L`.
Although this should probably be dealt with upstream before we patch it and as stated musl doesn't support C23 atm. (and the final C23 standard will not be published until earlier next year)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (16 preceding siblings ...)
2023-10-31 5:18 ` oreo639
@ 2023-10-31 5:18 ` oreo639
2023-10-31 5:19 ` oreo639
` (17 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:18 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1042 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 this issue.
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)` same as 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`.
The proper workaround here would be to `#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L`.
Although this should probably be dealt with upstream before we patch it and as stated musl doesn't support C23 atm. (and the final C23 standard will not be published until earlier next year)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (17 preceding siblings ...)
2023-10-31 5:18 ` oreo639
@ 2023-10-31 5:19 ` oreo639
2023-10-31 5:20 ` oreo639
` (16 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:19 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1063 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 this issue.
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`.
The proper workaround here would be to `#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L`.
Although this should probably be dealt with upstream before we patch it and as stated musl doesn't support C23 atm. (and the final C23 standard will not be published until earlier next year)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (18 preceding siblings ...)
2023-10-31 5:19 ` oreo639
@ 2023-10-31 5:20 ` oreo639
2023-10-31 5:23 ` oreo639
` (15 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:20 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1126 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 this issue.
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`.
The proper workaround here would be to:
```
#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
//Do nothing
#else
//k&r style declaration
#endif
```
Although this should probably be dealt with upstream before we patch it and as stated musl doesn't support C23 atm. (and the final C23 standard will not be published until earlier next year)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (19 preceding siblings ...)
2023-10-31 5:20 ` oreo639
@ 2023-10-31 5:23 ` oreo639
2023-10-31 5:24 ` oreo639
` (14 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:23 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1083 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 this issue.
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`.
The proper workaround here would be to:
```
#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
//Do nothing
#else
//k&r style declaration
#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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (20 preceding siblings ...)
2023-10-31 5:23 ` oreo639
@ 2023-10-31 5:24 ` oreo639
2023-10-31 5:24 ` oreo639
` (13 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:24 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1168 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 this issue.
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`.
The proper workaround here would be to:
```
#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
//Do nothing
#else
//k&r style declaration
#endif
```
Similar to what gcc does for `stdbool.h` (which was also made irrelevant in C23).
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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (21 preceding siblings ...)
2023-10-31 5:24 ` oreo639
@ 2023-10-31 5:24 ` oreo639
2023-10-31 5:26 ` oreo639
` (12 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:24 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1163 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 this issue.
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`.
The proper workaround here would be to:
```
#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
//Do nothing
#else
//k&r style declaration
#endif
```
Similar to what gcc does for `stdbool.h` (which was made irrelevant in C23).
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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (22 preceding siblings ...)
2023-10-31 5:24 ` oreo639
@ 2023-10-31 5:26 ` oreo639
2023-10-31 5:26 ` oreo639
` (11 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1188 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 this issue.
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`.
The proper workaround here would smth like:
```
#if defined(__cplusplus) || (defined(__STDC_VERSION__) && __STDC_VERSION__ > 201710L)
//Do nothing
#else
char *basename();
#endif
```
Similar to what gcc does for `stdbool.h` (which was made irrelevant in C23).
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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (23 preceding siblings ...)
2023-10-31 5:26 ` oreo639
@ 2023-10-31 5:26 ` oreo639
2023-10-31 5:27 ` oreo639
` (10 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1169 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 this issue.
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`.
The proper workaround here would smth like:
```
#if !defined(__cplusplus) || !(defined(__STDC_VERSION__) && __STDC_VERSION__ > 201710L)
char *basename();
#endif
```
Similar to what gcc does for `stdbool.h` (which was made irrelevant in C23).
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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (24 preceding siblings ...)
2023-10-31 5:26 ` oreo639
@ 2023-10-31 5:27 ` oreo639
2023-10-31 5:29 ` oreo639
` (9 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:27 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1091 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 this issue.
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`.
The proper workaround here would 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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (25 preceding siblings ...)
2023-10-31 5:27 ` oreo639
@ 2023-10-31 5:29 ` oreo639
2023-10-31 5:31 ` oreo639
` (8 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:29 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1091 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 this issue.
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`.
The proper workaround here would 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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (26 preceding siblings ...)
2023-10-31 5:29 ` oreo639
@ 2023-10-31 5:31 ` oreo639
2023-10-31 5:31 ` oreo639
` (7 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:31 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1159 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 this issue.
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 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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (27 preceding siblings ...)
2023-10-31 5:31 ` oreo639
@ 2023-10-31 5:31 ` oreo639
2023-10-31 5:34 ` oreo639
` (6 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:31 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1162 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 this issue.
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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (28 preceding siblings ...)
2023-10-31 5:31 ` oreo639
@ 2023-10-31 5:34 ` oreo639
2023-10-31 5:35 ` oreo639
` (5 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:34 UTC (permalink / raw)
To: ml
[-- 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)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (29 preceding siblings ...)
2023-10-31 5:34 ` oreo639
@ 2023-10-31 5:35 ` oreo639
2023-10-31 5:37 ` oreo639
` (4 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:35 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1179 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 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 published until earlier next year)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (30 preceding siblings ...)
2023-10-31 5:35 ` oreo639
@ 2023-10-31 5:37 ` oreo639
2023-10-31 5:44 ` oreo639
` (3 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:37 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1242 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 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 published until earlier next year)
https://en.cppreference.com/w/c/language/function_declaration
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (31 preceding siblings ...)
2023-10-31 5:37 ` oreo639
@ 2023-10-31 5:44 ` oreo639
2023-12-03 1:12 ` [ISSUE] [CLOSED] " ahesford
` (2 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-10-31 5:44 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1258 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 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ISSUE] [CLOSED] /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (32 preceding siblings ...)
2023-10-31 5:44 ` oreo639
@ 2023-12-03 1:12 ` ahesford
2023-12-03 1:12 ` ahesford
2024-01-22 21:47 ` oreo639
35 siblings, 0 replies; 37+ messages in thread
From: ahesford @ 2023-12-03 1:12 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
Closed issue by cazfi on void-packages repository
https://github.com/void-linux/void-packages/issues/46959
Description:
### 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (33 preceding siblings ...)
2023-12-03 1:12 ` [ISSUE] [CLOSED] " ahesford
@ 2023-12-03 1:12 ` ahesford
2024-01-22 21:47 ` oreo639
35 siblings, 0 replies; 37+ messages in thread
From: ahesford @ 2023-12-03 1:12 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1837299424
Comment:
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: /usr/include/string.h bad basename() prototype
2023-10-29 18:47 [ISSUE] /usr/include/string.h bad basename() prototype cazfi
` (34 preceding siblings ...)
2023-12-03 1:12 ` ahesford
@ 2024-01-22 21:47 ` oreo639
35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2024-01-22 21:47 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]
New comment by oreo639 on void-packages repository
https://github.com/void-linux/void-packages/issues/46959#issuecomment-1904877828
Comment:
This issue was fixed upstream: https://github.com/bminor/musl/commit/725e17ed6dff4d0cd22487bb64470881e86a92e7
The patch has been imported to: https://github.com/void-linux/void-packages/pull/45500
^ permalink raw reply [flat|nested] 37+ messages in thread