Paul Eggert writes:
> On 6/30/24 13:14, Po Lu wrote:
>> I think there should be a trivial test for a functional strnlen in
>> strnlen.m4, since it would be terrible to duplicate what ought to be the
>> responsibility of Gnulib in Emacs's configure.ac.
>
> Here's a first cut at doing that, as a pa
On 6/30/24 13:14, Po Lu wrote:
I think there should be a trivial test for a functional strnlen in
strnlen.m4, since it would be terrible to duplicate what ought to be the
responsibility of Gnulib in Emacs's configure.ac.
Here's a first cut at doing that, as a patch to Emacs master that I have
On 7/11/24 17:50, Eric Blake wrote:
In contrast, it's not OK to call memchr ("", 0, SIZE_MAX).
...this claim appears to be unsupported. Both C23 and POSIX 2024
state that memchr() "...shall behave as if it reads the characters
sequentially and stops as soon as a matching character is found",
On Wed, Jun 26, 2024 at 05:33:55PM GMT, Paul Eggert wrote:
> On 6/26/24 07:57, Bruno Haible wrote:
> > Po Lu wrote:
> > > I believe that the semantics of the POSIX specification of this GNU
> > > function omit the implied guarantee that strnlen will never examine
> > > bytes beyond the first null b
On Wed, Jul 10, 2024 at 01:55:51AM GMT, Paul Eggert wrote:
> On 7/9/24 22:03, Eric Blake wrote:
> > https://www.austingroupbugs.net/view.php?id=1834#c6830
> >
> > The current draft of proposed wording would have the C standard state:
> >
> > 2 The strnlen function counts not more than n character
On Tue, Jul 9, 2024 at 7:56 PM Paul Eggert wrote:
>
> On 7/9/24 22:03, Eric Blake wrote:
> > https://www.austingroupbugs.net/view.php?id=1834#c6830
> >
> > The current draft of proposed wording would have the C standard state:
> >
> > 2 The strnlen function counts not more than n characters (a nul
On 7/9/24 22:03, Eric Blake wrote:
https://www.austingroupbugs.net/view.php?id=1834#c6830
The current draft of proposed wording would have the C standard state:
2 The strnlen function counts not more than n characters (a null
character and characters that follow it are not counted) in the array
On Wed, Jun 26, 2024 at 05:33:55PM GMT, Paul Eggert wrote:
> On 6/26/24 07:57, Bruno Haible wrote:
> > Po Lu wrote:
> > > I believe that the semantics of the POSIX specification of this GNU
> > > function omit the implied guarantee that strnlen will never examine
> > > bytes beyond the first null b
On 7/1/24 02:16, Po Lu wrote:
but Gnulib (and by extension Emacs) does not invoke the Autoconf
test:
AC_DEFUN([gl_FUNC_STRNLEN],
[
AC_REQUIRE([gl_STRING_H_DEFAULTS])
dnl Persuade glibc to declare strnlen().
AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
AC_CHECK_DECLS_ONCE([strnlen]) <--
Paul Eggert writes:
> Autoconf's existing AC_FUNC_STRNLEN uses AC_RUN_IFELSE so this
> wouldn't work as-is.
>
> Perhaps you could write up a patch against Autoconf? That wouldn't
> count against the Gnulib quota
Sure, but Gnulib (and by extension Emacs) does not invoke the Autoconf
test:
A
On 6/30/24 13:18, Po Lu wrote:
How many lines remain of my 15-line quota of contributions to Gnulib?
I wouldn't worry about the quota; we can solve that problem later as
need be.
#if defined __ANDROID_API__ && (__ANDROID_API__ < 21)
you lose
#endif /* defined __ANDROID_API__ && (__ANDROID
Paul Eggert writes:
> Please feel free to write that. It's not something that would be easy
> for me to do, as I don't know Android. Also, I don't know that it'd be
> that trivial, as it might involve replacing the AC_FUNC_STRNLEN macro
> of Autoconf (and we should propagate that fix into Autocon
On 6/30/24 12:14, Po Lu wrote:
I think there should be a trivial test for a functional strnlen in
strnlen.m4
Please feel free to write that. It's not something that would be easy
for me to do, as I don't know Android. Also, I don't know that it'd be
that trivial, as it might involve replacing
Paul Eggert writes:
> On 6/27/24 01:55, Po Lu wrote:
>> 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.
>
>
Paul Eggert writes:
> On 6/27/24 02:37, Po Lu wrote:
>
>> Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is
>> incorrect?
>
> Thanks for pointing that out. I installed the attached into Gnulib and
> propagated it into Emacs master. Although I don't know of any
> practical, su
On 6/27/24 01:55, Po Lu wrote:
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.
Thanks, I don't know all the ins and
On 6/27/24 02:37, Po Lu wrote:
Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is
incorrect?
Thanks for pointing that out. I installed the attached into Gnulib and
propagated it into Emacs master. Although I don't know of any practical,
supported platform where this matte
Po Lu writes:
> Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is
> incorrect?
>
> size_t
> strnlen (const char *string, size_t maxlen)
> {
> const char *end = memchr (string, '\0', maxlen);
> return end ? (size_t) (end - string) : maxlen;
> }
>
> is virtually identical t
Paul Eggert writes:
> On 6/26/24 12:33, Paul Eggert wrote:
>> I installed the attached patch to document the Android 5.0 glitch
>
> Oops, attached the wrong patch. Here's the patch I meant to attach.
Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is
incorrect?
size_t
strnle
Paul Eggert 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 f
On 6/26/24 12:33, Paul Eggert wrote:
I installed the attached patch to document the Android 5.0 glitch
Oops, attached the wrong patch. Here's the patch I meant to attach.From a03728ed45b8fae66fb30aa808dde76e4d57d865 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 26 Jun 2024 17:16:06 +01
On 6/26/24 07:57, Bruno Haible wrote:
Po Lu wrote:
I believe that the semantics of the POSIX specification of this GNU
function omit the implied guarantee that strnlen will never examine
bytes beyond the first null byte
There is no such guarantee, not even implied.
There seems to be some con
Bruno Haible writes:
> When the text says "the array S of size MAXLEN", it means that the bytes
> S[0], S[1], ..., S[MAXLEN-1] must be accessible. Which is not the case if
> you pass MAXLEN as > ~(uintptr_t)S.
>
> The implementation could, for example, examine
> S[0], S[MAXLEN-1], S[1], S[MAXLE
Po Lu wrote:
> I believe that the semantics of the POSIX specification of this GNU
> function omit the implied guarantee that strnlen will never examine
> bytes beyond the first null byte
There is no such guarantee, not even implied.
> , made in (libc)String Length:
>
> If the array S of si
Bruno Haible writes:
> This memchr invocation is wrong. memchr is defined in ISO C23 § 7.26.5.2
> "The memchr generic function locates the first occurrence of c (...)
>in the initial n characters (...) of the object pointed to by s."
> The term "object" being defined in § 3.15:
> "region
Hi,
Po Lu wrote:
> It has been brought to my attention that a defective memchr is
> distributed with certain Android E-book readers with Android 2.3.5 that
> is liable to integer overflows with large values of N:
>
> memchr ("", 0, SIZE_MAX);
This memchr invocation is wrong. memchr is defined
Po Lu writes:
> disassembly of libc.so samples extracted from real Android devices
> reveals that defective versions of memchr are present until Android 4.3,
> API level 18.
Correction, up to API level 22 on architectures without specific
implementations of memrchr, as these issues suggest:
h
It has been brought to my attention that a defective memchr is
distributed with certain Android E-book readers with Android 2.3.5 that
is liable to integer overflows with large values of N:
memchr ("", 0, SIZE_MAX);
returns NULL, since:
Dump of assembler code for function memchr:
0xafd20644
28 matches
Mail list logo
