On 01/16/2017 04:00 PM, Kamil Dudka wrote: > On Monday, January 16, 2017 11:57:03 Paul Eggert wrote: >> Kamil Dudka wrote: >>> It can cause a real crash in certain execution environments. >> >> Which ones? I'm not interested in environments like -fsanitize=undefined, >> which is designed to catch violations of the standard. I want to know of a >> real execution environment where memcpy (0, 0, 0) does something bad, and >> why it does so. > > Have you actually looked at the discussion I referenced? > > It was about memchr (0, 'a', 0) causing SIGSEGV without -fsanitize=undefined: > > https://lists.gnu.org/archive/html/bug-gnulib/2009-05/msg00081.html
The thread went on to point out that it was a glibc bug for doing so, and that quality-of-implementation meant that glibc was patched to no longer have that bug. In other words, strengthening POSIX to guarantee something (that the pointer is never dereferenced, therefore undefined behavior never triggered, on zero size) beyond what the C standard leaves unspecified has actual cases where implementations either already get it right or are willing to fix code to get it right. > > I am not sure about memcpy (0, 0, 0) in particular but, in principle, I see > no difference between those two cases. And the principle is that POSIX is allowed to make guarantees where the C standard left things unspecified, particularly if those guarantees are already something that many coders are already relying on because they don't know any better. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
