[PATCH 06/11] Sptr: avoided potentially undefined behaviour.
max.romanov at gmail.com
Sat Jun 18 13:27:30 UTC 2022
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.
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.
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
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 *)
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the unit