Alejandro Colomar
May 22, 2023 10:26AM
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

> What makes you think that compiler is free to assume that you've
> wrote only to the y.t member, and not just some bytes in the y
> object?

Even if memcpy(3) is allowed to write bytes to subobjects beyond
the one pointed to by the pointer passed to it, I'm not convinced
that this has a valid meaning when there is no subobject which to
write. Since in this case, the write happens to padding bytes in
the parent object, I'm not sure if the GCC extension applies to
padding bytes.

So, according to ISO C, I'm now convinced that it's UB, even via
memcpy(3). According to the more relaxed GNU C rules, I'm not
sure, since it's not even documented. We only know that it seems
to work so far.

Cheers,
Alex

--
http://www.alejandro-colomar.es/
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

[PATCH] QUIC: better sockaddr initialization

Maxim Dounin 360 May 20, 2023 09:44PM

Re: [PATCH] QUIC: better sockaddr initialization

Roman Arutyunyan 121 May 21, 2023 05:08AM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 128 May 21, 2023 08:58AM

Re: [PATCH] QUIC: better sockaddr initialization

Alejandro Colomar 144 May 21, 2023 05:32AM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 128 May 21, 2023 09:12AM

Re: [PATCH] QUIC: better sockaddr initialization

Alejandro Colomar 125 May 21, 2023 10:36AM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 127 May 21, 2023 05:24PM

Re: [PATCH] QUIC: better sockaddr initialization

Alejandro Colomar 161 May 21, 2023 07:08PM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 129 May 21, 2023 10:36PM

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

Alejandro Colomar 180 May 22, 2023 10:26AM

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

Maxim Dounin 190 May 22, 2023 04:06PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 127
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready