Date: Fri, 15 May 2020 17:20:09 -0400
On Fri, May 15, 2020 at 9:30 AM J Decker via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On Wed, May 13, 2020 at 7:03 AM yo mizu via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> The issue really stems from big endian platforms... in memory (starting at
> 100d)
>
> 100 - 00 00 01 A4
>
> the address of the 'char' that is in that integer is +3 from the start of
> the pointer.
> This means that casting a int* to a char* may cause a shift to the pointer
> value; and worse, the conversion back from char* to int* may not know how
> many chars to unwind to get back to the start? (or maybe, going to a
> short* inbetween?)
>
> It's not so painful in a little endian world
>
> 100 - A4 01 00 00
>
> 100 is all the same for char*, short*, int* ,...
>
The C++ object model is nonsense, and you can't reason from nonsense.
The correct way to think about this, the way it's been done from the
early days of C, is that an object occupies a region of storage in
memory, a pointer to the object is the lowest address of that region
of storage, reinterpret_cast of that pointer to a different pointer
type is a no-op at runtime, and indirecting through such a pointer
treats the sizeof(TO_TYPE) lowest bytes of the storage as if it held
an object of TO_TYPE.
In my vision, memory is a bag of bits, and you can look at that bag
through the lens of any type and get whatever object of that type that
is represented by those bits. There is no such thing as "strict aliasing".
Any write to memory invalidates all cached vales (e.g., in registers)
unless the compiler can prove that the write wouldn't affect them.
The optimizationist compiler community has committed itself to willfully
disobeying what programmers write in their code, in patterns that go back
half a century. Instead of optimization being the transformation of code
into semantically equivalent forms that improve some metric, it has become
the task of finding more and more clever ways to break user intentions,
blithely saying "oh, you couldn't possibly have meant that" and discarding
swathes of code.
std-discussion_at_[hidden]> wrote:
> On Wed, May 13, 2020 at 7:03 AM yo mizu via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> The issue really stems from big endian platforms... in memory (starting at
> 100d)
>
> 100 - 00 00 01 A4
>
> the address of the 'char' that is in that integer is +3 from the start of
> the pointer.
> This means that casting a int* to a char* may cause a shift to the pointer
> value; and worse, the conversion back from char* to int* may not know how
> many chars to unwind to get back to the start? (or maybe, going to a
> short* inbetween?)
>
> It's not so painful in a little endian world
>
> 100 - A4 01 00 00
>
> 100 is all the same for char*, short*, int* ,...
>
The C++ object model is nonsense, and you can't reason from nonsense.
The correct way to think about this, the way it's been done from the
early days of C, is that an object occupies a region of storage in
memory, a pointer to the object is the lowest address of that region
of storage, reinterpret_cast of that pointer to a different pointer
type is a no-op at runtime, and indirecting through such a pointer
treats the sizeof(TO_TYPE) lowest bytes of the storage as if it held
an object of TO_TYPE.
In my vision, memory is a bag of bits, and you can look at that bag
through the lens of any type and get whatever object of that type that
is represented by those bits. There is no such thing as "strict aliasing".
Any write to memory invalidates all cached vales (e.g., in registers)
unless the compiler can prove that the write wouldn't affect them.
The optimizationist compiler community has committed itself to willfully
disobeying what programmers write in their code, in patterns that go back
half a century. Instead of optimization being the transformation of code
into semantically equivalent forms that improve some metric, it has become
the task of finding more and more clever ways to break user intentions,
blithely saying "oh, you couldn't possibly have meant that" and discarding
swathes of code.
Received on 2020-05-15 16:23:25