bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

required memchr behavior (was: [PATCH] tests/test-strstr.c: Add another


From: Eric Blake
Subject: required memchr behavior (was: [PATCH] tests/test-strstr.c: Add another self-test.)
Date: Fri, 29 May 2009 11:33:20 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 5/26/2009 4:05 PM:
> Eric Blake wrote:
>> http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml
>>
>> It looks like the bug is alpha-specific in memchr
> 
> I don't think it is a bug. memchr could also be implemented by doing
> a backwards search and still be conforming to ISO C99 and POSIX:

The Austin Group disagrees with you.  Here is the results from the meeting
yesterday
(https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=12144):

> XSHbug3.txt ERN 39 memchr  Accept as marked below
> 
> A number of changes were agreed as follows
> 
> Change p1284 lines 42163-42164
> In the DESCRIPTION remove "of the object" from
> 
> The memchr( ) function shall locate the first occurrence of c (converted
> to an unsigned char) in the initial n bytes (each interpreted as unsigned
> char) of the object pointed to by s.
> 
> In the RETURN VALUE section
> 
> The memchr( ) function shall return a pointer to the located byte,
> or a null pointer if the byte does not occur in the object.
> 
> to
> The memchr( ) function shall return a pointer to the located byte,
> or a null pointer if the byte is not found.
> 
> Also Nick will let the C committee know about the issue
> 
> Add to DESCRIPTION
> Implementations shall behave as if they read the memory byte by byte
> from the beginning of the bytes pointed to by s and stop at the first
> occurrence of c.


Therefore, your claim that:

> 
>> in anything else that
>> uses memchr to search for a trailing \0 with a length longer than the
>> allocated memory
> 
> It is such uses of memchr() that are buggy. When you call memchr(s,c,n), you
> must guarantee read access for the bytes at s, ..., s+n-1.

is incorrect.  It looks like the problems with glibc memchr on x86_64 are
present in glibc 2.10, but fixed in git:
http://sourceware.org/bugzilla/show_bug.cgi?id=10162

But as there are systems in the wild with the broken implementation, we
should probably start worrying about replacing the buggy memchr
implementations.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkogHGAACgkQ84KuGfSFAYD0TwCgodaw91x/8MXcStP/LwyL3zKQ
kHUAoKCXU1yfdnVRfxG9CKFPU2t2NOxq
=s/7L
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]