non-standard const-preserving string APIs

[Samuel Bronson]

On Mon, May 18, 2026, 1:19 PM Adhemerval Zanella Netto <
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> 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 ...)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260518/63c388d6/attachment.htm>