SASANO Takayoshi <u...@mx5.nisiq.net> wrote: > My issue is OpenBSD's memcpy() cannot handle overlapped area > and memcpy() within
Those are incorrect words. The issue is that memcpy() as defined by the standard does not handle overlapping areas, it is UNDEFINED what happens if you overlap the strings. The CSRG bcopy() would handle overlapping strings, by doing the copy backwards. In the C standard, if you want the bcopy() type operation you must call memmove() instead. There were times in the past where memcpy() was a layer on top of a bcopy(), but the standard does not promise this, and non-overlap memcpy() are way more common now. These bugs really should be found. So many years ago, I intentionally modified the OpenBSD's libc memcpy() to look for overlapping strings, and *REPORT THEM* via syslog, and abort(). This means memcpy() is less optimal since the overlap-and-report code wasn't written in asm for each architecture, instead we just use common C code. Obviously, sometimes memcpy are inlined by the compiler, and the libc/string/memcpy.o code won't be reached to perform the diagnostic check. So this doesn't catch all the bugs. The compiler may know that some cases are backwards -- maybe it warns? I doubt it performs those operations backwards, like memmove(). I suspect it generates undefined output in some cases. But by doing this in libc, the idea was that we would find enough of these bugs, and eventually stop finding them, then we could remove the check. Unfortunately, it keeps finding them. The really surprising thing is it finds it in places that we really expect would have been tested better. I mean this is unzip, surely someone has put effort into making sure it is perfect, because this is a fairly simple program often run against untrusted input. This suggests that the greater ecosystem is still far less tested for this typf of error. I continue to be surprised...
