Maxim Dounin
May 22, 2023 04:06PM
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/
_______________________________________________
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 257 May 20, 2023 09:44PM

Re: [PATCH] QUIC: better sockaddr initialization

Roman Arutyunyan 73 May 21, 2023 05:08AM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 72 May 21, 2023 08:58AM

Re: [PATCH] QUIC: better sockaddr initialization

Alejandro Colomar 88 May 21, 2023 05:32AM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 77 May 21, 2023 09:12AM

Re: [PATCH] QUIC: better sockaddr initialization

Alejandro Colomar 69 May 21, 2023 10:36AM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 79 May 21, 2023 05:24PM

Re: [PATCH] QUIC: better sockaddr initialization

Alejandro Colomar 105 May 21, 2023 07:08PM

Re: [PATCH] QUIC: better sockaddr initialization

Maxim Dounin 76 May 21, 2023 10:36PM

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

Alejandro Colomar 106 May 22, 2023 10:26AM

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

Maxim Dounin 119 May 22, 2023 04:06PM



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

Online Users

Guests: 126
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready