-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to ebb9@byu.net on 5/27/2009 6:58 AM:
> Likewise, application writers have noticed that it is possible to
> write faster code for finding a NUL byte, if one is present within a
> bounded length, by using memchr rather than strnlen, since the former
> has fewer conditionals (bounds check and search for NUL) than the
> latter (bounds check, search for NUL, and search for c).
Correction - I meant to compare memchr(s,c,n) to strchr(s,c) where c is
known to occur in s; strchr requires a search for c and for NUL, and the
search for two bytes in parallel is typically more expensive than a bounds
check and single search. There is no strnchr, so nothing is standardized
that performs all three of bounds check, search for NUL, and search for c
at once. (That behavior is also useful--for example, gnulib provides a
function memchr2--but it can wait for another day to be standardized).
But one point remains - many applications use memchr(s,0,n) rather than
strnlen(s,n) because strnlen was not present in earlier standards. So
this aardvark is still useful in standardizing this relationship.
> Change the rationale at line 42174 from:
>
> None.
>
> to:
>
> Although C99 is silent on the behavior of memchr when s points to an
> array smaller than n bytes, this specification requires memchr to
> behave as if it accesses bytes in ascending order, thus making
> memchr(s,0,n) safe to use as a faster alternative to strnlen(s,n) when
> determining if the end of a null-terminated string occurs within n
> bytes.
Therefore, we may want to strike the word 'faster' in this proposed rationale.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----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
iEYEARECAAYFAkodQHkACgkQ84KuGfSFAYCerwCfcRyH4YWNxgIZJ1bQkuRnRHHF
92sAoMR/IbfG43FD0MFzHdf8EwsV/AHI
=6Tsv
-----END PGP SIGNATURE-----
|