non-standard const-preserving string APIs

non-standard const-preserving string APIs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

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?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: non-standard const-preserving string APIs

[Adhemerval Zanella Netto]

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?

Re: non-standard const-preserving string APIs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

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!


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: <cover.1776882798.git.alx@kernel.org>

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: non-standard const-preserving string APIs

[Adhemerval Zanella Netto]

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).

I am not sure if he still keep his objection, nor if it is would a blocker for
this new api.

Re: non-standard const-preserving string APIs

[Adhemerval Zanella Netto]

On 18/05/26 15:17, Samuel Bronson wrote:
> On Mon, May 18, 2026, 1:19 PM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> 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).
> 
> 
> 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: <cover.1776882798.git.alx@kernel.org>

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

Re: non-standard const-preserving string APIs

[Florian Weimer]

* Adhemerval Zanella Netto:

> 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).

<https://inbox.sourceware.org/libc-alpha/lhums05zjuh.fsf@oldenburg.str.redhat.com/>

> 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

Re: non-standard const-preserving string APIs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

Hi Florian,

On 2026-06-01T13:41:16+0200, Florian Weimer wrote:
> > 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/lhums05zjuh.fsf@oldenburg.str.redhat.com/>
> 
> > 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.

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

> 
> Thanks,
> Florian
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]