This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 10/29/2010 11:49 AM, David A. Ramos wrote: > Hi newlib maintainers, > > Our checking tools (KLEE) keeps complaining about newlib's generic strlen version. It looks like it was patched back in May 2008 to include a speed hack that violates ISO C. It attempts to first word align the pointer, and then read a word at a time to check for a NULL: > > libc/string/strlen.c: > 73 /* If the string is word-aligned, we can check for the presence of > 74 a null in each word-sized block. */ > 75 aligned_addr = (unsigned long *)str; > 76 while (!DETECTNULL (*aligned_addr)) > 77 aligned_addr++; > > Obviously, this can read out of bounds if the memory allocated to that string is less than a word in length. While on most architectures this wouldn't actually cause a segfault, I don't think that's a safe assumption for the generic version of a libc routine. The same patch included an i386 target containing the same algorithm, which may be perfectly acceptable. > > Thoughts? As long as reading beyond the end of a string does not fault, you can't detect the violation of the standard, so the as-if rule applies. Prove to me that there is an architecture that can fault on anything less than a word boundary, and then we'll talk about changing the code. Until then, this implementation may violate strict C89, but it is by all means portable to all possible platforms that newlib will ever target. And while you can indeed detect that you are reading beyond bounds by using tools such as valgrind, I don't consider that as a valid argument to be worth changing the code (you should instead be installing valgrind exceptions to document the fact that we are knowingly reading beyond bounds, but that the end result of that extraneous read does not affect program execution because we are not basing any decisions off of that extra data). -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |