https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #54 from Julian Seward <jsew...@acm.org> --- (In reply to Andreas Arnez from comment #50) > In the meantime I noticed that we have another fundamental problem that > comes with GCC's inlined strlen: The last vector load (VL, or with length = > VLL) may read past an allocated buffer, causing an "invalid read". But of > course reading beyond the buffer is actually OK, as long as no page boundary > is crossed and the data beyond the buffer is ignored. I'm not sure how to > get rid of these false positives. Any advice? Memcheck's "partial-loads-OK" heuristic, which is now enabled by default, should remove these complaints. So the question is, why isn't it? See mc_LOADV_128_or_256_slow in mc_main.c. To be clear, what this heuristic allows is: * a 16 byte load, with 16 byte alignment, which loads memory over a transition over a buffer end, will not report an error * instead, the bytes loaded from the area inside the buffer are marked with the definedness of the loaded data. The bytes corresponding to the area beyond the end of the buffer are marked as undefined. * Hence, provided the loaded data after the terminating zero is ignored, there will be no error. It would help a lot to have a proper answers to the questions I asked in comments 44 and 47. To be blunt, I am not happy to have this stuff land until there's a proper discussion of the implementation strategy for these vector loads. It is not enough that programs using these vector load instructions run correctly. It is also necessary that they describe the data flow accurately enough that Memcheck is not going to produce a lot of false positives on strlen-like code. But so far I am not convinced that that is the case. -- You are receiving this mail because: You are watching all bug changes.
