[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strchrnul speed
From: |
Eric Blake |
Subject: |
Re: strchrnul speed |
Date: |
Mon, 28 Apr 2008 21:44:47 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Ben Pfaff <blp <at> cs.stanford.edu> writes:
> > Any objections against this patch? I ask because it intentionally
> > violates the C99 constraint of not reading beyond the end of an array.
> > However, the excess read can only occur on the final longword of an array,
> > and only with an aligned longword read, so on all hardware I know of, the
> > read won't fault even though it reads more bytes than strictly necessary;
> > people accessing volatile I/O memory with side effects on read should not
> > be using strchrnul in the first place. This code gives a much faster
> > search than the original byte-wise approach.
>
> This approach will cause false-positive warnings under memory
> debuggers such as Valgrind. However, anyone who notices such a
> warning should be able to spot from the comments in the function
> that it is still correct code given the assumption you have
> above, so I don't think that is a big deal.
Given that, and the fact that the (less-efficient) glibc implementation also
reads beyond bounds:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/string/strchrnul.c?
rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc
So I've gone ahead and committed this.
--
Eric Blake
- Re: memrchr speed, (continued)
Re: memchr speed, Simon Josefsson, 2008/04/28
Re: memchr2 speed, gcc, Bruno Haible, 2008/04/26
Re: strchrnul speed, Eric Blake, 2008/04/28
Re: strchrnul speed, Eric Blake, 2008/04/28