memcpy(3), strict aliasing, pointer provenance rules (was: [PATCH] QUIC: better sockaddr initialization)

[Maxim Dounin]

Hello!

On Mon, May 22, 2023 at 04:23:56PM +0200, Alejandro Colomar wrote:

> Hello!
> 
> On 5/22/23 04:35, Maxim Dounin wrote:
> [...]
> 
> > As you've correctly noticed, your example is different from the 
> > nginx code, since it uses a local variable (and not an allocated 
> > object, like nginx does).
> > 
> > The next question you might consider is: what difference it makes?  
> > And if at all?  In particular, you might want to consider what 
> > memcpy() actually does.  As per the quoted paragraph, it does two 
> > things:
> > 
> > 1. Modifies the object as pointed out by (void *) &y.t;
> > 
> > 2. Changes the effective type of the modified object for 
> >    subsequent accesses (to the effective type of the object from 
> >    which the value is copied) if there is no declared type.
> > 
> > For your example, (2) is not relevant, since there is a 
> > declared type.  So the remaining part is (1).
> 
> Agree.
> 
> In fact, I'm now closer to thinking that the same thing via
> malloc(3) was similarly UB.
> 
> > 
> > What actually memcpy() modifies, and what it is allowed to modify?  
> 
> According to ISO C, memcpy() isn't special in this regard.  6.5.6
> (Additive operators) applies:
> <https://port70.net/~nsz/c/c11/n1570.html#6.5.6>
> 
> So accesses outside the bounds of the (sub)object to which the
> pointer points, are UB, even via memcpy(3).
> 
> You won't find any specification that memcpy(3) is allowed to
> cross subobject boundaries in order to copy bytes.
> 
> However, GCC relaxes the rules for mem*() functions in an
> undocumented way, so that memcpy() can cross subobject boundaries
> to perform the copy.  I asked that GCC documents this, and
> specifies under which rules this works, and what are the limits.
> 
> str*() functions seem to have gotten the same exception recently
> in GCC.
> 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259>

While this is an interesting ticket, I don't think that Martin 
Sebor's interpretation of the standard that pointers are not 
allowed to cross subobject boundaries is correct.  As outlined in 
the comments, this makes it impossible to obtain a pointer to the 
outer object, which is a common task in C.

[...]

-- 
Maxim Dounin
http://mdounin.ru/