3 ms·
These all look to read beyond the end of the string, which can cause a crash. Don't they need a scalar handling of <16 byte suffixes, or at least aligning to av
by millstone 9y ago
These all look to read beyond the end of the string, which can cause a crash. Don't they need a scalar handling of <16 byte suffixes, or at least aligning to avoid crossing a page?
- chrisseaton 9y agoAren't the reads aligned? Is it possible for an aligned 16 byte block to cross a page boundary?
- millstone 9y ago"The strings do not need to be aligned" and the code doesn't take special pains to align the reads.
- Twirrim 9y agoIt mentions on the site: Other features of SSE 4.2 The strings do not need to be aligned. The processor properly handles end-of-the-string case for zero-terminated strings and Pascal-style strings. You can use the instructions with Unicode characters, signed or unsigned bytes. Four aggregation operations can be used to implement a wide range of string-processing functions. So presumably not, looks like the processor handles the end-of-string stuff natively.
- millstone 9y agoThis seems impossible, and besides there's code like `MovDqU xmm0, dqword[edx]` which will certainly SIGSEGV if crossing a page boundary into unmapped address space. I also found this SO question which claims that trivial testcases break these implementations https://stackoverflow.com/questions/21714827/movdqu-instruction-page-boundary https://stackoverflow.com/questions/21714827/movdqu-instruct... This code is just horrendously broken. Why has nobody else noticed it?