[...] > This code is based on memchr() and in case that > memchr() does any speed > optimization via extended word lengths, the code does > not follow the POSIX > standard as POSIX requires not to touch any data > behind "len". > > Jörg
memchr() probably shouldn't be going too far either; even though it doesn't explicitly have the same restriction, neither does it have permission to look past the length bytes starting at the pointer. The C of memchr is ok. As far as I understand them, I think the assembler versions are also being careful not to look past the area they're supposed to check. At least, I think the x86 versions are; the SPARC versions are a little too creative for me to follow without taking a lot of time and aspirin. I did some tests to check for looking past the end. They aren't perfect, because they require that the area in which it may be ok to look _ends_ at a page boundary (so the next page can have no permissions such that accessing it would cause an obvious memory violation). So they don't cover the case where the area to be searched ends other than on word boundaries. (But they work fine with cases where it doesn't start on a word alignment.) One could try other ending alignments and trace them to be sure they're ok. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
