Re: [PATCH] dfa: port to gcc -fsanitize=undefined

[Eric Blake]

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