On Tue, Apr 29, 2014 at 02:53:32PM -0500, Patrick Baggett wrote: > On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett > <baggett.patr...@gmail.com>wrote: > > > Yes, that's the one. Interestingly, in glibc-2.19, this change is > > reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU. > > Oddly, in glibc git, the buggy version appears. > > > > > > > I've filed a bug with glibc [1] and let the author know that there is a > problem. In the meantime, I'll try to figure out what the problem is. I > think we may need to file a debian bug though since it will require a glibc > update. Sebastien, can you handle that?
It looks to me as if the problem might be here: sub rWORD1, r0101, rTMP2 If rWORD1 is 0x0100 ???? ???? ???? (in case of strcmp('\0001', '\0000'), then you get something like: 0x0100 ???? ???? ???? - 0x0101 0101 0101 0101 which goes negative. If the first byte is 0x02 or higher, that doesn't happen, so for typical strings it is not a problem. And once it goes negative, I think the pattern the algorithm expected to use is completely gone. It can't find the NULL bytes anymore. At least that's how it appears to me. I didn't quite finish making sense of it. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429204726.gx17...@csclub.uwaterloo.ca