[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: test-memchr failure on rawhide
From: |
Bruno Haible |
Subject: |
Re: test-memchr failure on rawhide |
Date: |
Fri, 8 May 2009 13:18:18 +0200 |
User-agent: |
KMail/1.9.9 |
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
been working fine for decades on all platforms.
For no reason other than standards-pickiness. It's not even a matter of
speed, because this behaviour implies an additional conditional branch
instruction that tests for a NULL pointer. (glibc certainly does not
make the mistake of accessing ptr[0] when n = 0, this would be wrong
also when ptr is pointing to an I/O mapped address range, and would cause
unnecessary L1 cache operations when ptr is pointing to regular memory.)
Bruno
- test-memchr failure on rawhide, Jim Meyering, 2009/05/07
- Re: test-memchr failure on rawhide, Andreas Schwab, 2009/05/08
- Re: test-memchr failure on rawhide, Bruno Haible, 2009/05/08
- Re: test-memchr failure on rawhide, Andreas Schwab, 2009/05/08
- Re: test-memchr failure on rawhide,
Bruno Haible <=
- Re: test-memchr failure on rawhide, Andreas Schwab, 2009/05/08
- Re: test-memchr failure on rawhide, Bruno Haible, 2009/05/08
- Re: test-memchr failure on rawhide, James Youngman, 2009/05/08
- Re: test-memchr failure on rawhide, Bruno Haible, 2009/05/08
- Re: test-memchr failure on rawhide, Andreas Schwab, 2009/05/09
- Re: test-memchr failure on rawhide, Bruno Haible, 2009/05/09
- Re: test-memchr failure on rawhide, Andreas Schwab, 2009/05/09
- Re: test-memchr failure on rawhide, Bruno Haible, 2009/05/09
- Re: test-memchr failure on rawhide, Andreas Schwab, 2009/05/09
- Re: test-memchr failure on rawhide, Bruno Haible, 2009/05/11