I wrote:
> This is more hairy than you might think. Because of the GCC attribute syntax.
>
> stdio.in.h does
>
> /* Don't break __attribute__((format(printf,M,N))). */
> #define printf __printf__
>
> because there are not many symbols that can be used in place of 'printf'.
>
> Do you have
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
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 Collin,
> I've committed these two patches adjusting idpriv-drop and
> idpriv-droptemp which previously stored the result of getuid () and
> getgid () in an 'int'.
The first patch is obviously fine.
The second patch makes the assumption that uid_t and gid_t are
at least 32-bits wide. I had wr
On Tue, Jun 25, 2024 at 06:46:04PM +0200, Bruno Haible wrote:
> > Building shared libraries which depend upon
> > other libraries breaks whenever a dependency found (by something like
> > AC_SEARCH_LIBS) was not built with -fPIC (or whatever
> > the name of this option might be on the platform in q
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:
> 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
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
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 Wed, 26 Jun 2024, Bruno Haible wrote:
> The second patch makes the assumption that uid_t and gid_t are
> at least 32-bits wide. I had written the code that way because on some
> systems (SunOS 4 IIRC, older IRIX, and Linux [1]) uid_t and gid_t
> had been 'unsigned short', and thus a comparison
Tim Rice wrote:
> OpenServer 5 uses 'unsigned short'.
> ...
> tim@timosr5d 6% egrep 'gid_t|uid_t' /usr/include/sys/types.h
> typedef unsigned short uid_t;
> typedef unsigned short gid_t;
> ...
>
> Still a current product.
SCO OpenServer 5 is not supported by Gnulib [1].
Adding support for SCO
On Wed, 26 Jun 2024, Bruno Haible wrote:
> Tim Rice wrote:
> > OpenServer 5 uses 'unsigned short'.
> > ...
> > tim@timosr5d 6% egrep 'gid_t|uid_t' /usr/include/sys/types.h
> > typedef unsigned short uid_t;
> > typedef unsigned short gid_t;
> > ...
> >
> > Still a current product.
>
> SCO OpenS
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
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
14 matches
Mail list logo
