Re: non-standard const-preserving string APIs

[Florian Weimer <fweimer@redhat.com>]

* 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