Hi Michal,

On Tue, 14 Apr 2026 at 11:28:41 +0200, Michal Suchánek wrote:
> On Tue, Apr 14, 2026 at 06:51:36PM +1000, Seth McDonald via isync-devel wrote:
> > Our memrchr() implementation must cast away const from the 's'
> > parameter, which causes a compiler warning.  Locally suppress this
> > warning for the relevant cast.
> 
> it actually does not have to.
> 
> It's quite possible to make the return value also const.
> 
> It's not how the standard defines the function but not everything in the
> standard makes sense.

To my knowledge, memrchr() is a nonstandard GNU extension, so it isn't
"as bad" to change the function signature.  However, we only have a
definition of the function for the situation in which the provided
standard library does not include it.  So if we change the signature for
our implementation, then the function's signature will be different in
different compilation environments:

- If memrchr() is present in the standard library, the signature will
  have a non-const return value.
- If memrchr() is not present, the signature will instead have a const
  return value.

While I agree a const return value would be better, having different
signatures in different environments would be worse.  A single invariant
codebase makes debugging and portability much easier.  Which in this
case may manifest as ensuring compilation does not succeed in only some
environments but fail in others.

Take care,
        Seth McDonald.

-- 
E9D1 26A5 F0D4 9DF7 792B  C2E2 B4BF 4530 D39B 2D51


_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to