non-standard const-preserving string APIs
Alejandro Colomar
maintainerHi!
I'm working on documenting the recent API change of strchr(3) et al. to adapt to C23. While doing that, I've realized that the related APIs that are not standardized by ISO C, such as memrchr(3), have not been changed consistently with their relatives. Has this been discussed?
I think the inconsistency might be dangerous. Should we change the other string functions accordingly?
Have a lovely day!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 9 lines · Alejandro Colomar
Hi!
I'm working on documenting the recent API change of strchr(3) et al. to adapt to C23. While doing that, I've realized that the related APIs that are not standardized by ISO C, such as memrchr(3), have not been changed consistently with their relatives. Has this been discussed?
I think the inconsistency might be dangerous. Should we change the other string functions accordingly?
I think it is reasonable to support const-preserving to the GNU interfaces as well. Are you preparing a patch?
Alejandro Colomar
maintainerHi Adhemerval,
Quoted 10 lines · Adhemerval Zanella Netto
Quoted 7 lines · Alejandro Colomar
Hi!
I'm working on documenting the recent API change of strchr(3) et al. to adapt to C23. While doing that, I've realized that the related APIs that are not standardized by ISO C, such as memrchr(3), have not been changed consistently with their relatives. Has this been discussed?
Quoted 4 lines
Quoted 2 lines
I think the inconsistency might be dangerous. Should we change the other string functions accordingly?
I think it is reasonable to support const-preserving to the GNU interfaces as well. Are you preparing a patch?
Yup, I will. Thanks!
Have a lovely day!
Alex
P.S.: Adhemerval, would you mind having a look at my other recent patch set? It was 'Add [v]aprintf(3)'. The message-ID was:
Message-ID: <[email protected]>
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 13 lines · Alejandro Colomar
Hi Adhemerval,
Quoted 10 lines · Adhemerval Zanella Netto
Quoted 7 lines · Alejandro Colomar
Hi!
I'm working on documenting the recent API change of strchr(3) et al. to adapt to C23. While doing that, I've realized that the related APIs that are not standardized by ISO C, such as memrchr(3), have not been changed consistently with their relatives. Has this been discussed?
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
I think the inconsistency might be dangerous. Should we change the other string functions accordingly?
I think it is reasonable to support const-preserving to the GNU interfaces as well. Are you preparing a patch?
Yup, I will. Thanks!
I will try to take a look, but I recall from previous weekly calls that Florian has raised objection that this does not solve the overflow issue (not without further extra changes).
I am not sure if he still keep his objection, nor if it is would a blocker for this new api.
Quoted 27 lines · Samuel Bronson
On Mon, May 18, 2026, 1:19 PM Adhemerval Zanella Netto <[email protected] <mailto:[email protected]>> wrote:
On 17/05/26 10:59, Alejandro Colomar wrote:
> Hi Adhemerval,
>
> On 2026-05-17T09:22:41-0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 16/05/26 15:15, Alejandro Colomar wrote:
>>> Hi!
>>>
>>> I'm working on documenting the recent API change of strchr(3) et al. >>> to adapt to C23. While doing that, I've realized that the related APIs >>> that are not standardized by ISO C, such as memrchr(3), have not been >>> changed consistently with their relatives. Has this been discussed? >>>
>>> I think the inconsistency might be dangerous. Should we change the >>> other string functions accordingly?
>> I think it is reasonable to support const-preserving to the GNU interfaces as >> well. Are you preparing a patch?
>
> Yup, I will. Thanks!
I will try to take a look, but I recall from previous weekly calls that Florian has raised objection that this does not solve the overflow issue (not without further extra changes).
Quoted 6 lines
I'm having trouble finding messages that seem relevant: <https://inbox.sourceware.org/libc-alpha/?q=memrchr+f%3AFlorian <https://inbox.sourceware.org/libc-alpha/?q=memrchr+f%3AFlorian>> only turns up a few messages, most of them patches; I'm working from the assumption that Florian does not exclusively use patch descriptions to convey such information? Perhaps it was on another list, or another function was mentioned, or wildcards were used? (Or it was somebody else's opinion you were thinking of? Or public-inbox doesn't go that far back?)
Can you find the message?
(Or I guess we could wait for Florian to chime in ...)
Sorry if I was being confusing, I was replying to the PS:
P.S.: Adhemerval, would you mind having a look at my other recent patch set? It was 'Add [v]aprintf(3)'. The message-ID was:
Message-ID: <[email protected]>
Not for this proposal itself.
And Florian's remarks can be found on the previous version [1]. He add a bit more on the weekly call some weeks ago, I don't recall the context in full.
[1] https://sourceware.org/pipermail/libc-alpha/2026-March/176018.html
* Adhemerval Zanella Netto:
Quoted 16 lines · Alejandro Colomar
Quoted 15 lines
Hi Adhemerval,
Quoted 12 lines · Adhemerval Zanella Netto
Quoted 9 lines · Alejandro Colomar
Hi!
I'm working on documenting the recent API change of strchr(3) et al. to adapt to C23. While doing that, I've realized that the related APIs that are not standardized by ISO C, such as memrchr(3), have not been changed consistently with their relatives. Has this been discussed?
I think the inconsistency might be dangerous. Should we change the other string functions accordingly?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think it is reasonable to support const-preserving to the GNU interfaces as well. Are you preparing a patch?
Yup, I will. Thanks!
I will try to take a look, but I recall from previous weekly calls that Florian has raised objection that this does not solve the overflow issue (not without further extra changes).
<https://inbox.sourceware.org/libc-alpha/[email protected]/>
Quoted 2 lines
I am not sure if he still keep his objection, nor if it is would a blocker for this new api.
I still think we should fix it. Maybe rename the “done” variable in the vfprintf internals to “ssize_t”, and then gradually fix the compilation failures, investigating whether the change is correct in context. We need to add some early bailout in case INT_MAX is crossed for the non-aprintf case.
Thanks,
Florian
Alejandro Colomar
maintainerHi Florian,
Quoted 6 lines · Florian Weimer
Quoted 3 lines
I will try to take a look, but I recall from previous weekly calls that Florian has raised objection that this does not solve the overflow issue (not without further extra changes).
<https://inbox.sourceware.org/libc-alpha/[email protected]/>
Quoted 8 lines
Quoted 2 lines
I am not sure if he still keep his objection, nor if it is would a blocker for this new api.
I still think we should fix it. Maybe rename the “done” variable in the vfprintf internals to “ssize_t”, and then gradually fix the compilation failures, investigating whether the change is correct in context. We need to add some early bailout in case
INT_MAXis crossed for the non-aprintf case.
Would you mind at least confirming whether the current patches are OK modulo the EOVERFLOW issue? It's the first time I touch many of these files (e.g., abilist files), and I'd appreciate if you reviewed it so that I can forget about that part.
Have a lovely night!
Alex
Quoted 4 lines
Thanks,
Florian
Signature · 1 line
<https://www.alejandro-colomar.es>