[PATCH 06/11] Sptr: avoided potentially undefined behaviour.
alx.manpages at gmail.com
Fri Jun 17 23:15:46 UTC 2022
On 6/18/22 01:04, Max Romanov wrote:
> I'm sorry to be a pain,
No problem :)
but the key thing is: ".. read from another
In this case, ISO C uses the term object to refer to a broader concept,
that includes any variable.
region of data storage in the execution environment, the contents of
which can represent values
> In the statement you are trying to "fix", the "base" does not
> actually _read_ from the object (structure, to be precise), instead the
> address of the structure itself used. In other words, "p->base" is a
> shortcut for "(uint8_t *) p".
the region of data storage pointed to by `p->base` would be an object
(of type uint8_t, or maybe uint8_t).
But the pointer itself does constitute another separate object. And
that object is the one that is stored in the union (the uint8_t data is
not stored in the union, but in some other allocated memory (probably)).
Since we are reading a member of the union (and each member is an
object, by definition, even if it's a pointer), and storing the value
into another member of the union, that's not valid.
As pointed by @supercat in StackOverflow (in the link I provided), the
rationale was probably to allow compilers to do some optimizations, or
for example, copy byte by byte; in archs where the union members are
larger than a register, this will definitely cause a bug; in archs where
the union members fit into a register (as in our case), the code is
likely to work, but the standard makes no guarantees about it, and a
compiler may still do bad stuff. It's better to be safe.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the unit