-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/13/2009 5:40 PM:
> Eric and Jim wrote:
>> Looks good.
>
> OK, I committed the patch.
$ ./gnulib-tool --with-tests --test memchr
...
executing aclocal -I ../glm4
configure.ac:103: warning: AC_COMPILE_IFELSE was called be
Eric and Jim wrote:
> Looks good.
OK, I committed the patch.
Bruno
Bruno Haible wrote:
> Jakub Jelinek, when closing the two reported glibc bugs, agreed with
> our interpretation that a NULL pointer is an invalid argument to memchr
> but a pointer to a zero-sized memory region is valid.
>
> Here is a proposed patch to make the gnulib unit tests compliant,
> withou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/12/2009 6:49 PM:
> Jakub Jelinek, when closing the two reported glibc bugs, agreed with
> our interpretation that a NULL pointer is an invalid argument to memchr
> but a pointer to a zero-sized memory region is valid.
>
Jakub Jelinek, when closing the two reported glibc bugs, agreed with
our interpretation that a NULL pointer is an invalid argument to memchr
but a pointer to a zero-sized memory region is valid.
Here is a proposed patch to make the gnulib unit tests compliant,
without removing the particular test.
Bruno Haible writes:
> Andreas Schwab wrote:
>> > And in the context of memchr's return value:
>>
>> The context is irrelevant.
>
> You couldn't tell how many bytes memchr is searching through?
Where did I say that???
> glibc's memchr is accessing n+1 bytes in the special case of n = 0. That i
Andreas Schwab wrote:
> > And in the context of memchr's return value:
>
> The context is irrelevant.
You couldn't tell how many bytes memchr is searching through? I tell you:
n bytes. This is clear from ISO C 99 paragraph 7.21.5.1.(2).
glibc's memchr is accessing n+1 bytes in the special case o
Hi Jim,
> This one segfaults on the memchr-induced access:
>
> memchr () at ../sysdeps/x86_64/memchr.S:31
> 31 movdqa (%rdi), %xmm0
Thank you for testing. I entered a different bug about this one,
which will not so easy to close with reference with ISO C 99:
https://bugzi
Bruno Haible wrote:
> Ben Pfaff wrote:
>> Yes. C99 7.2.21p2 says:
> [In my copy of C99 this is 7.21.1p2.]
>>
>> Where an argument declared as size_t n specifies the length
>> of the array for a function, n can have the value zero on a
>> call to that function. Unless explicitly sta
Ben Pfaff wrote:
> Yes. C99 7.2.21p2 says:
[In my copy of C99 this is 7.21.1p2.]
>
> Where an argument declared as size_t n specifies the length
> of the array for a function, n can have the value zero on a
> call to that function. Unless explicitly stated otherwise
> in the
Bruno Haible writes:
> Do you mean to say that none of the functions
> memchr
> memcmp
> memcpy
> memmove
> memset
> wmemchr
> wmemcmp
> wmemcpy
> wmemmove
> wmemset
> may be called with arguments ptr = NULL and n = 0 ?
Yes. C99 7.2.21p2 says:
Where an argument declare
Bruno Haible writes:
> Andreas Schwab wrote:
>> > What is "the object"?
>>
>> See section 3.14 in the C standard.
>>
>> region of data storage in the execution environment, the contents of
>> which can represent values
>
> And in the context of memchr's return value:
The context is irr
Andreas Schwab wrote:
> > What is "the object"?
>
> See section 3.14 in the C standard.
>
> region of data storage in the execution environment, the contents of
> which can represent values
And in the context of memchr's return value:
"The memchr function returns a pointer to the loca
Bruno Haible writes:
> What is "the object"?
See section 3.14 in the C standard.
region of data storage in the execution environment, the contents of
which can represent values
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5
Andreas Schwab wrote:
> s/worked fine earlier/invoked undefined behviour/
In your interpretation of the C99 standard: can you please tell, regarding
this sentence in section 7.21.5.1, and assuming a call memchr(ptr,c,n) with
ptr != NULL and n >= 0:
"The memchr function returns a pointer to the
Bruno Haible writes:
> Does memchr(ptr,c,0) for ptr != NULL now access ptr[0] or not?
The as-if rule allows everything as long as a strictly compliant program
cannot tell the difference.
> In both cases the memchr implementation is deviating from traditional
> behaviour and provoking crashes fo
James Youngman wrote:
> > How many bytes is "the object" large?
>
> If s is NULL, there _is_ no object.
> ...
> NULL is not a pointer to an object.
This is not what I'm arguing about.
Does memchr(ptr,c,0) for ptr != NULL now access ptr[0] or not?
If yes, then when ptr is a pointer that points p
On Fri, May 8, 2009 at 11:21 PM, Bruno Haible wrote:
> Andreas Schwab wrote:
>> They are free to access the object in any random order they like.
>
> The question is: How many bytes are the mem* functions free to access?
>
> How many bytes is "the object" large?
If s is NULL, there _is_ no object
Andreas Schwab wrote:
> They are free to access the object in any random order they like.
The question is: How many bytes are the mem* functions free to access?
How many bytes is "the object" large?
ISO C 99 7.21.5.1 says:
"The memchr function locates the first occurrence of c (converted to a
Bruno Haible writes:
> also when ptr is pointing to an I/O mapped address range
You certainly cannot use any of the mem functions for volatile memory
anyway. They are free to access the object in any random order they
like.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprin
Andreas Schwab wrote:
> > This would certainly be a departure from historical practice.
>
> Implementations are free to define undefined behaviour any way they
> like. The C standard imposes no restrictions on that behaviour.
The question is whether glibc wants to make programs crash, that have
Jim Meyering writes:
> When the specified length is 0, memchr must not dereference the
> pointer.
The C standard does not support your opinion.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something com
Bruno Haible writes:
> Andreas Schwab wrote:
>> This is not a bug. NULL is not a valid object pointer.
>
> Do you mean to say that none of the functions
> memchr
> memcmp
> memcpy
> memmove
> memset
> wmemchr
> wmemcmp
> wmemcpy
> wmemmove
> wmemset
> may be called with argum
Andreas Schwab wrote:
> Jim Meyering writes:
>> cat > k.c <<\EOF
>> #include
>> int main() { return !!(memchr (0, 'a', 0)); }
>> EOF
>> gcc -O k.c; ./a.out
>> Segmentation fault
>> [Exit 139 (SIGSEGV)]
>
> This is not a bug. NULL is not a valid object pointer.
It may not be a POSIX conformance
Andreas Schwab wrote:
> This is not a bug. NULL is not a valid object pointer.
Do you mean to say that none of the functions
memchr
memcmp
memcpy
memmove
memset
wmemchr
wmemcmp
wmemcpy
wmemmove
wmemset
may be called with arguments ptr = NULL and n = 0 ?
This would certainly b
Jim Meyering writes:
> cat > k.c <<\EOF
> #include
> int main() { return !!(memchr (0, 'a', 0)); }
> EOF
> gcc -O k.c; ./a.out
> Segmentation fault
> [Exit 139 (SIGSEGV)]
This is not a bug. NULL is not a valid object pointer.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerp
FYI, while doing pre-release testing for coreutils-7.4, I noticed a
single gnulib test failure on Fedora rawhide. It looks like a bug in
's memchr macro. Reported here:
http://bugzilla.redhat.com/499689
Quick summary:
cat > k.c <<\EOF
#include
int main() { return !!(memchr (0, 'a', 0)); }
27 matches
Mail list logo
