[PATCH 06/11] Sptr: avoided potentially undefined behaviour.

[Max Romanov]

I'm appreciate your patience and effort to make it clear!

I also admit it is not obvious way to describe the relocatable offset in C.

--
Max

-----Original Message-----
From: Alejandro Colomar <alx.manpages at gmail.com>
To: Max Romanov <max.romanov at gmail.com>, Andrew Clayton <andrew at digital-domain.net>
Cc: unit at nginx.org
Sent: сб, 18 июн. 2022 14:00
Subject: Re: [PATCH 06/11] Sptr: avoided potentially undefined behaviour.

Hi Max,

On 6/18/22 11:39, Max Romanov wrote:

> The pointer to structure's field does not stored in the structure. And 
> reading the pointer to the field is just adding an offset to the object 
> pointer.

Okay, now I got it.

So, p->base is reinterpreting as uint_8[], the contents of some stucture.
p, the pointer to the union, is really a pointer to that structure.
p->base, when used in pointer arithmetics, decays to a pointer to the 
first element, which is the same as a pointer to the union, which is the 
same as a pointer to the reinterpreted structure.
And p->offset is just an offset to that pointer, so it's the offset of 
ptr to the start to the structure (reinterpreted as a uint8_t[]), and 
it's stored as the first element of said structure.

Now it makes sense.

So, yes, the patch was wrong, and the linter has a bug (but they'll 
probably ignore it because unions in C++ are so crap that it doesn't pay 
out fixing it).

> 
> Why do you ignore my suggestion to replace "p->base" with "(uint8_t *) 
> p"

Sory, I misunderstood it yesterday.

> and try to understand the purpose of the object, 'base' and 'offset'? 
> Instead you digging the specifications to prove the validation software 
> behavior.

Thanks!

Alex


-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/unit/attachments/20220618/b3870c2d/attachment.htm>