Re: Integer overflows in memchr

[Po Lu]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Actually it's not incorrect because Android's memchr no longer has
> undefined behavior with calls like memchr ("", 0, SIZE_MAX); it
> reliably returns its first argument in that particular
> example. Although this goes beyond what C and POSIX require for
> memchr, it's OK for Android memchr to do that as an extension, and
> it's OK for Android's strnlen to rely on Android's extensions to
> memchr.
>
> I installed the attached patch to document the Android 5.0
> glitch. Since Android 5.0 is no longer supported I hope we don't need
> to worry about this in Gnulib. That being said, if it's important for
> free software to run on these old unsupported platforms and if someone
> wants to update the Gnulib strnlen module to work around this Android
> 5.0 bug, I would think that'd be OK.

Google continue to support SDKs from 19 onwards in the standard support
library:

  
https://android-developers.googleblog.com/2023/10/androidx-minsdkversion-19.html

which is the real threshold at which official support ends.  Granted,
Emacs supports versions still older than 4.4, e.g. 2.3.5 and 2.2, where
this bug was encountered by real users and reported.