On Tue, Apr 14, 2015 at 04:39:44PM +0100, Dimitris Papastamos wrote: > On Tue, Apr 14, 2015 at 04:33:56PM +0100, Connor Lane Smith wrote: > > On 14 April 2015 at 13:50, Dimitris Papastamos <s...@2f30.org> wrote: > > > dst and src are required to be valid objects even if n is 0, otherwise > > > this is undefined behaviour. > > > > I looked this up in C11. Seems to be the case: > > > > > 7.24.2.1.2. The memcpy function copies n characters from the object > > > pointed to by s2 into the object pointed to by s1. > > > > > 6.2.6.1.2. Except for bit-fields, objects are composed of contiguous > > > sequences of one or more bytes, ... > > > > > 124) ... there are no pointers to or arrays of bit-field objects. > > > > An object pointed to by s1 or s2 is guaranteed to be at least 1 byte > > long, so memcpy is free to dereference the first byte of either, > > whether or not n > 0. > > > > I think it's a mistake that a libc actually go ahead and do this, but > > the C standard suggests that it is permitted, so we should certainly > > do the check. > > Yup, well it happens only with the optimized version of memmove() in OpenBSD. > Not sure if this was intended or not. In any case, it is valid for libc > to assume that src/dst is at least 1 byte long even if n is 0 as you say. >
Yeah, see here, under null objects: http://www.tedunangst.com/flak/post/zero-size-objects This should be reverted. -- Omar
