On 6/14/2023 4:01 PM, Chris M. Thomasson wrote:
> On 6/14/2023 3:27 PM, James Kuyper wrote:
>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>>
>>>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>>>> an `uint64_t`; that's nonsense.
>>>>
>>>> The reference intitially supplied by the caller is casted from a char
>>>> -array. memcpy() is the only legal way in C++ to alias that content.
>> ...
>>> So for the separately compiled function it does not matter technically,
>>> except possibly for performance, whether it uses clear, concise, safe
>>> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>>>
>>> That means that regarding this matter the common interpretation of the
>>> standard is not technical but instead specifies a formal UB that can't
>>> happen unless one informs a really perverse compiler that it's there.
>>
>> All you need is a platform where misaligned pointers do not merely cause
>> the code to be inefficient, but to actually malfunction. On such a
>> platform, if p_bytes is not correctly aligned to store a uint64_t, then
>> the code will malfunction in the reinterpret_cast<>.
> [...]
>
> What about some code that crosses a L2 cache line boundary and causes
> the damn processor to assert a bus lock... Argh!
>

CMPXCHG on an address that points to data that straddles a l2 cache line
should do it... I cannot remember for sure if the LOCK prefix _has_ to
be present here... Cannot remember right that detail right now, damn!
Fwiw, XCHG should assert bus lock as well wrt the "bad" location, and
LOCK is automatically implied in XCHG to begin with.

On 6/15/2023 1:50 AM, Chris M. Thomasson wrote:
> On 6/14/2023 4:01 PM, Chris M. Thomasson wrote:
>> On 6/14/2023 3:27 PM, James Kuyper wrote:
>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>>>
>>>>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>>>>> an `uint64_t`; that's nonsense.
>>>>>
>>>>> The reference intitially supplied by the caller is casted from a char
>>>>> -array. memcpy() is the only legal way in C++ to alias that content.
>>> ...
>>>> So for the separately compiled function it does not matter technically,
>>>> except possibly for performance, whether it uses clear, concise, safe
>>>> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>>>>
>>>> That means that regarding this matter the common interpretation of the
>>>> standard is not technical but instead specifies a formal UB that can't
>>>> happen unless one informs a really perverse compiler that it's there.
>>>
>>> All you need is a platform where misaligned pointers do not merely cause
>>> the code to be inefficient, but to actually malfunction. On such a
>>> platform, if p_bytes is not correctly aligned to store a uint64_t, then
>>> the code will malfunction in the reinterpret_cast<>.
>> [...]
>>
>> What about some code that crosses a L2 cache line boundary and causes
>> the damn processor to assert a bus lock... Argh!
>>
>
> CMPXCHG on an address that points to data that straddles a l2 cache line
> should do it... I cannot remember for sure if the LOCK prefix _has_ to
> be present here... Cannot remember right that detail right now, damn!
> Fwiw, XCHG should assert bus lock as well wrt the "bad" location, and
> LOCK is automatically implied in XCHG to begin with.

I also cannot remember if it only asserts the bus lock when there is
"contention" on a LOCK'ed atomic RMW using an address that goes to data
that straddles a l2 cache line on Intel. Its been a while since I have
worked with raw x86 asm. I am sure some of my work is up on the way back
machine. Let me check...

I found some of my old asm work!

This is MASM:

http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html

This should be GAS:

http://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

;^)

Am 14.06.2023 um 23:28 schrieb David Brown:

>> In C you can alias anything as a char-array and vise versa,
>> but not in C++.

> <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>
> <https://en.cppreference.com/w/cpp/types/byte>

There never will be an upcoming CPU where CHAR_BIT is not eight.
Even Posix requires that.

> Finally you have managed to check it, ...

I've checked it long before the posting of you before.

> No, it is still the wrong type regardless of the memory flatness.

You're paranoid.

On 15/06/2023 12:06, Bonita Montero wrote:
> Am 14.06.2023 um 23:28 schrieb David Brown:
>
>>> In C you can alias anything as a char-array and vise versa,
>>> but not in C++.
>
>> <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>
>> <https://en.cppreference.com/w/cpp/types/byte>
>
> There never will be an upcoming CPU where CHAR_BIT is not eight.
> Even Posix requires that.

To the nearest percent, 0% of all cpus shipped are used in POSIX systems.

CPUs are made all the time that don't have 8-bit char. Just because you
have a limited view, does not mean C, C++ or all other programmers do so.

Of course, none of that matters in the slightest here - nothing about
std::byte, type aliasing, or accessing via char types relies on char
being 8-bit.

>
>
> > Finally you have managed to check it, ...
>
> I've checked it long before the posting of you before.
>

Either you are lying in an attempt to look less incompetent, or you are
incompetent, or you wrote a poorly considered "optimisation" that
doesn't work at all in a major use-case and were so proud of your
half-arsed solution that you hoped no one would notice.

>> No, it is still the wrong type regardless of the memory flatness.
>
> You're paranoid.

No, understanding the point of basic language types is not paranoia.

On Wednesday, June 14, 2023 at 11:26:01 AM UTC-4, Bonita Montero wrote:
....
> In C you can alias anything as a char array and a char array as
> anything so it would be safe to alias anything as anything with
> double-casting (I guess that's correctly supported by the compilers).

C's anti-alasing rules are asymmetric. It distinguishes between the effective type of a object (which is the same as it'declared type, if it has one) and the typeof the league used to access it. Aliasing an object with an effect8ve type of uint64_t using an lvalue of character type is allowed by the following clause:

"An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
....
- a character type" (6.5p7)

Accessing an object with an effective type that is a character type (or an array thereof) using an lvalue with a type of uint64_t is not allowed by any of the cases listed in that paragraph unless they are members of the same union, (or if uint64_t is a character type, which is pretty unlikely, but permitted).

Am 15.06.2023 um 15:05 schrieb David Brown:
> On 15/06/2023 12:06, Bonita Montero wrote:
>> Am 14.06.2023 um 23:28 schrieb David Brown:
>>
>>>> In C you can alias anything as a char-array and vise versa,
>>>> but not in C++.
>>
>>> <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>
>>> <https://en.cppreference.com/w/cpp/types/byte>
>>
>> There never will be an upcoming CPU where CHAR_BIT is not eight.
>> Even Posix requires that.
>
> To the nearest percent, 0% of all cpus shipped are used in POSIX systems.
>
> CPUs are made all the time that don't have 8-bit char.  Just because you
> have a limited view, does not mean C, C++ or all other programmers do so.

CPUs with CHAR_BIT != 8 are rare and there won't be any further
in the future.

> Of course, none of that matters in the slightest here - nothing about
> std::byte, type aliasing, or accessing via char types relies on char
> being 8-bit.
>
>>
>>
>>  > Finally you have managed to check it, ...
>>
>> I've checked it long before the posting of you before.
>>
>
> Either you are lying in an attempt to look less incompetent, ...

I checked it, you didn't.

> incompetent, or you wrote a poorly considered "optimisation" that
> doesn't work at all in a major use-case and were so proud of your
> half-arsed solution that you hoped no one would notice.
>
>>> No, it is still the wrong type regardless of the memory flatness.
>>
>> You're paranoid.
>
> No, understanding the point of basic language types is not paranoia.

I would never run into problems with that.
Your opinion is compulsive.

Am 15.06.2023 um 15:28 schrieb james...@alumni.caltech.edu:
> On Wednesday, June 14, 2023 at 11:26:01 AM UTC-4, Bonita Montero wrote:
> ...
>> In C you can alias anything as a char array and a char array as
>> anything so it would be safe to alias anything as anything with
>> double-casting (I guess that's correctly supported by the compilers).
>
> C's anti-alasing rules are asymmetric. It distinguishes between the effective type of a object (which is the same as it'declared type, if it has one) and the typeof the league used to access it. Aliasing an object with an effect8ve type of uint64_t using an lvalue of character type is allowed by the following clause:
>
> "An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
> ...
> - a character type" (6.5p7)
>
> Accessing an object with an effective type that is a character type (or an array thereof) using an lvalue with a type of uint64_t is not allowed by any of the cases listed in that paragraph unless they are members of the same union, (or if uint64_t is a character type, which is pretty unlikely, but permitted).

In C you can alias anything as a char-array and a a char-array as
anything. And you can alias signed, defaulted (char) or unsigned
entities as their counterparts. That's all.
Since aliasing with a union is very common all compiler support
that, although there's no guarantee from the standard for that.

On Thursday, June 15, 2023 at 9:43:04 AM UTC-4, Bonita Montero wrote:
> Am 15.06.2023 um 15:28 schrieb james...@alumni.caltech.edu:
> > On Wednesday, June 14, 2023 at 11:26:01 AM UTC-4, Bonita Montero wrote:
> > ...
> >> In C you can alias anything as a char array and a char array as
> >> anything so it would be safe to alias anything as anything with
> >> double-casting (I guess that's correctly supported by the compilers).
> >
> > C's anti-alasing rules are asymmetric. It distinguishes between the effective type of a object (which is the same as it'declared type, if it has one) and the typeof the league used to access it. Aliasing an object with an effect8ve type of uint64_t using an lvalue of character type is allowed by the following clause:
> >
> > "An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
> > ...
> > - a character type" (6.5p7)
> >
> > Accessing an object with an effective type that is a character type (or an array thereof) using an lvalue with a type of uint64_t is not allowed by any of the cases listed in that paragraph unless they are members of the same union, (or if uint64_t is a character type, which is pretty unlikely, but permitted).
> In C you can alias anything as a char-array and a a char-array as
> anything. And you can alias signed, defaulted (char) or unsigned
> entities as their counterparts. That's all.

Citation, please?
6,5p7 is a complete and exhaustive list of the situations where an object can be accessed with defined behaviorusing an lvaue with a type that is different from the effective type of that object. It starts with a "shall", so violations have undefined behavior. Please identify which item on that list covers the case where the lvalue is uint64_t and the effective type is an array of char.

> Since aliasing with a union is very common all compiler support
> that, although there's no guarantee from the standard for that.

There's a footnote in the C standard which says "If the member used to read the contents of a union object is not the same as the member last used to store a value in the object the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called type punning)."

Footnotes are non-normative. They are not supposed to contain the sole specification of some aspect if the language. They're only supposed to explain something that could be derived from the normative text of standard. I don'tbelieve that is the case for this footnote. I've discussed this issue with a couple of people, one of them a member of the committee, who disagreed. Neither of them was able to present an argument laying out that derivation, so I believe that you are technically correct.

However, what that footnote describes is the intent of the committee, and the expectation that almost all users of C have had since union's were first introduced, and the way essentially all real world implementors have implemented them. Therefore, I would recommend treating that footnote as if it were normative, until such time as the standard is corrected to say the same thing in normative text.

On 15/06/2023 15:35, Bonita Montero wrote:
> Am 15.06.2023 um 15:05 schrieb David Brown:
>> On 15/06/2023 12:06, Bonita Montero wrote:
>>> Am 14.06.2023 um 23:28 schrieb David Brown:
>>>
>>>>> In C you can alias anything as a char-array and vise versa,
>>>>> but not in C++.
>>>
>>>> <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>
>>>> <https://en.cppreference.com/w/cpp/types/byte>
>>>
>>> There never will be an upcoming CPU where CHAR_BIT is not eight.
>>> Even Posix requires that.
>>
>> To the nearest percent, 0% of all cpus shipped are used in POSIX systems.
>>
>> CPUs are made all the time that don't have 8-bit char.  Just because
>> you have a limited view, does not mean C, C++ or all other programmers
>> do so.
>
> CPUs with CHAR_BIT != 8 are rare and there won't be any further
> in the future.

You do understand that simply repeating something does not make it true?
Processors with char greater than 8 bits are niche, but certainly not
rare in numbers of devices delivered. I suppose it's fair to assume
that /you/ will never be programming any.

>
>> Of course, none of that matters in the slightest here - nothing about
>> std::byte, type aliasing, or accessing via char types relies on char
>> being 8-bit.
>>
>>>
>>>
>>>  > Finally you have managed to check it, ...
>>>
>>> I've checked it long before the posting of you before.
>>>
>>
>> Either you are lying in an attempt to look less incompetent, ...
>
> I checked it, you didn't.
>
>> incompetent, or you wrote a poorly considered "optimisation" that
>> doesn't work at all in a major use-case and were so proud of your
>> half-arsed solution that you hoped no one would notice.
>>
>>>> No, it is still the wrong type regardless of the memory flatness.
>>>
>>> You're paranoid.
>>
>> No, understanding the point of basic language types is not paranoia.
>
> I would never run into problems with that.
> Your opinion is compulsive.
>

"Compulsive" is not nearly as inaccurate as "paranoid" - I do prefer to
try to be accurate in my coding. If there is a type that fits a
particular usage, I'll use that rather than one that just happens to work.

Am 15.06.2023 um 20:35 schrieb David Brown:

> Processors with char greater than 8 bits are niche, but certainly not
> rare in numbers of devices delivered.  I suppose it's fair to assume
> that /you/ will never be programming any.

Almost any programmer is not programming for such CPUs. And you think
everything must be portable to such CPUs if you complain about that
for sources for which you don't understand its purpose. There's for
sure no C++-compiler which supports C++20 for systems that have CHAR_BIT
different than eight.

> "Compulsive" is not nearly as inaccurate as "paranoid" - I do prefer
> to try to be accurate in my coding. ...

.... if necessary. If it is not necessary it's just compulsiveness.

On 2023-06-15 12:27 AM, James Kuyper wrote:
> On 6/14/23 15:46, Alf P. Steinbach wrote:
>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>
>>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>>> an `uint64_t`; that's nonsense.
>>>
>>> The reference intitially supplied by the caller is casted from a char
>>> -array. memcpy() is the only legal way in C++ to alias that content.
> ...
>> So for the separately compiled function it does not matter technically,
>> except possibly for performance, whether it uses clear, concise, safe
>> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>>
>> That means that regarding this matter the common interpretation of the
>> standard is not technical but instead specifies a formal UB that can't
>> happen unless one informs a really perverse compiler that it's there.
>
> All you need is a platform where misaligned pointers do not merely cause
> the code to be inefficient, but to actually malfunction. On such a
> platform, if p_bytes is not correctly aligned to store a uint64_t, then
> the code will malfunction in the reinterpret_cast<>.

Yes, but irrelevant for the case discussed, because the values are
guaranteed correctly aligned.

[snip]
> If p_bytes is correctly aligned, simple assignment will work just as
> well as memcpy().

Yes.

>> Even g++'s documentation of `-fstrict-aliasing` says "A character type
>> may alias any other type.". ...
>
> True, but that's not what this reinterpret_cast does;

It is what this `reinterpret_cast` does.

> it aliases a
> character type with uint64_t, and that a problem if pbytes is not
> correctly aligned to hold a uint64_t.

It is correctly aligned.

> The anti-aliasing rules are not symmetric.

That's a tangential issue, and best discussed in a new thread.

- Alf

On 2023-06-15 10:06 AM, David Brown wrote:
> On 14/06/2023 21:46, Alf P. Steinbach wrote:
>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>
>>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>>> an `uint64_t`; that's nonsense.
>>>
>>> The reference intitially supplied by the caller is casted from a char
>>> -array. memcpy() is the only legal way in C++ to alias that content.
>>
>> When that function is separately compiled in a different translation
>> unit, how is the compiler to know when compiling calling code that the
>> function uses `memcpy` internally,
>>
>> and when compiling the function, how is the compiler to know that it's
>> generally called with a `*reinterpret_cast<uint64_t*>( p_bytes )` as
>> argument?
>>
>> Answer: it doesn't know, in either case.
>>
>> So generally (let's disregard global optimization with link time
>> compilation) `memcpy` versus `=` can't affect the outcome.
>>
>> So for the separately compiled function it does not matter
>> technically, except possibly for performance, whether it uses clear,
>> concise, safe and guaranteed max efficient `=`, or verbose and unsafe
>> `memcpy`.
>>
>
> Code that relies on limited optimisation or separate compilation for
> correct behaviour, is an extremely bad idea - it is fragile and a hidden
> bug waiting to explode in the future.  Shortcuts now will cost dearly
> later on.  Take pride in your work, and code responsibly - do what you
> can to make your code /correct/, rather than relying on weak tools!

Repeatedly copying lots of data instead of reinterpreting,

is inefficient and awkward and a source of bugs in itself.

`memcpy` is not the safest tool around. It's rather the opposite,
something to avoid /if possible/. `memcpy` is the "weak tool" here.

The problem is not the standard, which simply lacks wording for what was
obviously intended, like the wording in the g++ documentation, and which
at least in C++03 was a bit inconsistent re this issue (e.g. the
separate point about address of first item in a POD struct was not part
of the allegedly exhaustive strict aliasing list), but the problem is,
clearly, the C++ standardization committee and its interpretation.

Once you realize that it should not be hard to code responsibly.

- Alf

On 16/06/2023 08:59, Alf P. Steinbach wrote:
> On 2023-06-15 10:06 AM, David Brown wrote:
>> On 14/06/2023 21:46, Alf P. Steinbach wrote:
>>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>>
>>>>> It's copying an `uint64_t` that is known to be correctly aliased,
>>>>> to an `uint64_t`; that's nonsense.
>>>>
>>>> The reference intitially supplied by the caller is casted from a char
>>>> -array. memcpy() is the only legal way in C++ to alias that content.
>>>
>>> When that function is separately compiled in a different translation
>>> unit, how is the compiler to know when compiling calling code that
>>> the function uses `memcpy` internally,
>>>
>>> and when compiling the function, how is the compiler to know that
>>> it's generally called with a `*reinterpret_cast<uint64_t*>( p_bytes
>>> )` as argument?
>>>
>>> Answer: it doesn't know, in either case.
>>>
>>> So generally (let's disregard global optimization with link time
>>> compilation) `memcpy` versus `=` can't affect the outcome.
>>>
>>> So for the separately compiled function it does not matter
>>> technically, except possibly for performance, whether it uses clear,
>>> concise, safe and guaranteed max efficient `=`, or verbose and unsafe
>>> `memcpy`.
>>>
>>
>> Code that relies on limited optimisation or separate compilation for
>> correct behaviour, is an extremely bad idea - it is fragile and a
>> hidden bug waiting to explode in the future.  Shortcuts now will cost
>> dearly later on.  Take pride in your work, and code responsibly - do
>> what you can to make your code /correct/, rather than relying on weak
>> tools!
>
> Repeatedly copying lots of data instead of reinterpreting,
>
> is inefficient and awkward and a source of bugs in itself.

With a half-decent compiler, "copying" like this disappears in the
optimisation. But there's no disagreement that it is awkward and could
be a source of bugs (Bonita's half-way attempt at optimisation shows that).

Reinterpreting data as a different type from its real type is, in
general, undefined behaviour. Reinterpreting, such as by pointer casts
or reinterpret_cast<>, does not allow you to break the language's type
aliasing rules.

In C++20, there is an alternative to some related uses of memcpy() -
std::bit_cast<>. This is safer, because it hides messy details like the
size of the copy and fails to compile for inappropriate object types,
but in practice it is just a nice wrapper for a memcpy() with a little
"magic" to make it work as constexpr.

(If Bonita had been targeting C++20, presumably the code would have used
std::asumme_aligned instead of a gcc/clang extension.)

>
> `memcpy` is not the safest tool around. It's rather the opposite,
> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>

I don't know how the function here is supposed to be used. We know that
the pointer (it is syntactically a reference, but effectively a pointer)
is properly aligned for a uint64_t, but we don't know if it actually
points to a uint64_t. Perhaps it points to a double, or some other
64-bit type.

You are absolutely right that memcpy() is not a "safe" tool - used like
this, it is a way to bypass the normal safe typing of the language. But
it is a way to get around the rules, rather than break the rules. So if
you need to access the representation of one type as though it were a
different type, then memcpy (or equivalent use of std::byte or char
pointers) is the correct way to do it. So memcpy is not a /weak/ tool
here - it is the /best/ tool here. But you only use it if you need it.

The alternative you are suggesting - separately compiled functions - is
far less safe. It is a hidden bomb, waiting to cause trouble when later
compilers or flags combine code differently, or when someone moves the
function to a different part of the code. memcpy() is part of the
language, and is fully defined and documented behaviour, while separate
compilation is going outside the language and defined behaviour. It is
the most fragile solution, and /never/ one to be recommended.

> The problem is not the standard, which simply lacks wording for what was
> obviously intended, like the wording in the g++ documentation, and which
> at least in C++03 was a bit inconsistent re this issue (e.g. the
> separate point about address of first item in a POD struct was not part
> of the allegedly exhaustive strict aliasing list), but the problem is,
> clearly, the C++ standardization committee and its interpretation.
>

I don't think anyone would accuse the C++ standards of being too clear,
but the behaviour of memcpy is well documented and well defined. Bonita
is thoroughly confused about how and when access by character pointers
is defined behaviour in C and C++, but knows that memcpy works correctly
here. It is usually a better choice to use memcpy() than roll-your-own
character pointer access code anyway.

> Once you realize that it should not be hard to code responsibly.
>

Yes - you do so by writing code that has defined behaviour that does
what you want. You don't do it by relying on luck of compilation details.

On 2023-06-16 10:55 AM, David Brown wrote:
> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>
>> `memcpy` is not the safest tool around. It's rather the opposite,
>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>
>
> I don't know how the function here is supposed to be used.  We know that
> the pointer (it is syntactically a reference, but effectively a pointer)
> is properly aligned for a uint64_t, but we don't know if it actually
> points to a uint64_t.  Perhaps it points to a double, or some other
> 64-bit type.

In the case you sketch where the bits do not represent a valid
`uint64_t`, the `memcpy` does not make the behavior well-defined: that's
a (dangerous) misconception.

I'm not sure if you're addressing only the formal here.

However, if you intended this to also apply to the in-practice, then the
burden of proof is on you that some computer exists where `uint64_t` has
bits that do not participate in the value representation, so that they
/can/ be invalid: as far as I know there is no such computer.

- Alf

Am 16.06.2023 um 08:59 schrieb Alf P. Steinbach:

> `memcpy` is not the safest tool around. It's rather the opposite,
> something to avoid /if possible/. `memcpy` is the "weak tool" here.

I'm aliasing, so memcpy() is the only tool here.

On 16/06/2023 12:34, Alf P. Steinbach wrote:
> On 2023-06-16 10:55 AM, David Brown wrote:
>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>
>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>
>>
>> I don't know how the function here is supposed to be used.  We know
>> that the pointer (it is syntactically a reference, but effectively a
>> pointer) is properly aligned for a uint64_t, but we don't know if it
>> actually points to a uint64_t.  Perhaps it points to a double, or some
>> other 64-bit type.
>
> In the case you sketch where the bits do not represent a valid
> `uint64_t`, the `memcpy` does not make the behavior well-defined: that's
> a (dangerous) misconception.

A "uint64_t" has a guaranteed fully-defined format and no padding bits.
All possible bit patterns for the type have well-defined behaviour.
(Hypothetically, that would not be true for "unsigned long long", which
could contain padding bits and have could have trap representations.)

In case I am missing something, please tell me where you see any
possible dangerous or not fully defined behaviour even for the more
general case :

#include <string.h>
#include <stdint.h>

uint64_t read64bits(const void * p) {
uint64_t x;
memcpy((void*) &x, p, sizeof(uint64_t));
return x;
}

We can assume that "p" points to data of some type of at least 64 bits
in size. I would like to hear of any potential issues in C or C++
(hence the cross-language code).

>
> I'm not sure if you're addressing only the formal here.

No. It is a general principle. Some people /do/ believe that "separate
compilation" creates magical barriers that limit a compiler's ability to
see the relationships between code sections, and therefore its ability
to "optimise using assumptions about defined and undefined behaviours",
and that this means some kinds of undefined behaviours become defined by
moving code to a different file or disabling optimisation. They are
wrong to believe this. They may manage to write code that works when
they test it, but it will be fragile - the code still has exactly the
same undefined behaviours, and these may manifest as bugs in the future.

>
> However, if you intended this to also apply to the in-practice, then the
> burden of proof is on you that some computer exists where `uint64_t` has
> bits that do not participate in the value representation, so that they
> /can/ be invalid: as far as I know there is no such computer.
>

No, not at all. It is only /you/ that has suggested, by claiming the
use of memcpy is not fully defined, that uint64_t may hypothetically
contain padding bits. (See earlier in my reply.) I know it can't, so
that is not the issue.

My argument is that the following code is /wrong/, even if the functions
are compiled in separate sources :

uint64_t read64(const uint64_t * p) {
return *p;
}

uint64_t reinterpret(double x) {
return read64((const uint64_t *) &x);
}

If these are placed in separate files and compiled separately, with
today's compilers, with no link-time or whole-program optimisation, then
the code will work as the programmer expected and get a bit
representation of the double (which we assume is 64-bit). But working
in a test does not make it /correct/ code, and certainly not /good/ code.

David Brown <david.brown@hesbynett.no> writes:

> On 16/06/2023 12:34, Alf P. Steinbach wrote:
>> On 2023-06-16 10:55 AM, David Brown wrote:
>>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>>
>>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>>
>>>
>>> I don't know how the function here is supposed to be used.  We know that
>>> the pointer (it is syntactically a reference, but effectively a pointer)
>>> is properly aligned for a uint64_t, but we don't know if it actually
>>> points to a uint64_t.  Perhaps it points to a double, or some other
>>> 64-bit type.
>> In the case you sketch where the bits do not represent a valid
>> `uint64_t`, the `memcpy` does not make the behavior well-defined: that's
>> a (dangerous) misconception.
>
> A "uint64_t" has a guaranteed fully-defined format and no padding bits. All
> possible bit patterns for the type have well-defined
> behaviour.

"Fully-defined format" says, to my mind, more that you wanted to say.
In particular the significance of the bits is not defined.

> (Hypothetically, that would not be true for "unsigned long
> long", which could contain padding bits and have could have trap
> representations.)
>
> In case I am missing something, please tell me where you see any possible
> dangerous or not fully defined behaviour even for the more general case :
>
> #include <string.h>
> #include <stdint.h>
>
> uint64_t read64bits(const void * p) {
> uint64_t x;
> memcpy((void*) &x, p, sizeof(uint64_t));
> return x;
> }

What's not "fully defined behaviour" is the return value's relationship
to the bytes pointed to by p. I think you are using "fully defined
behaviour" to mean "not undefined behaviour", but since the former is
not a technical term in the language standards, a reader might take more
from it than you intended.

Yes, this is something of a nit-pick, I know.

--
Ben.

On 2023-06-16 2:55 PM, David Brown wrote:
> On 16/06/2023 12:34, Alf P. Steinbach wrote:
>> On 2023-06-16 10:55 AM, David Brown wrote:
>>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>>
>>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>>
>>> I don't know how the function here is supposed to be used.  We know
>>> that the pointer (it is syntactically a reference, but effectively a
>>> pointer) is properly aligned for a uint64_t, but we don't know if it
>>> actually points to a uint64_t.  Perhaps it points to a double, or
>>> some other 64-bit type.
>>
>> In the case you sketch where the bits do not represent a valid
>> `uint64_t`, the `memcpy` does not make the behavior well-defined:
>> that's a (dangerous) misconception.
>
> A "uint64_t" has a guaranteed fully-defined format and no padding bits.

Since you believe that, your comment about "Perhaps points to a double"
is meaningless nonsense.

You're arguing against yourself, with only three lines between your two
comments that are shooting dum-dum bullets at each other.

Make up your mind, please.

> All possible bit patterns for the type have well-defined behaviour.
> (Hypothetically, that would not be true for "unsigned long long", which
> could contain padding bits and have could have trap representations.)

We could discuss this assertion, e.g. I could helpfully mention that in
C++ "these requirements do not hold for other types [than character
types]", but better that you waste time attempting to PROVE IT.

Chapter and verse, please.

Not that it matters for what I've written, but it matters for the silly
argument that you offered, quoted above, and that you now argue against,
plus, there is the thing about being Wrong on the internet, not to
mention Doubly Wrong: just on principle one should not let that pass.

> In case I am missing something, please tell me where you see any
> possible dangerous or not fully defined behaviour even for the more
> general case :
>
> #include <string.h>
> #include <stdint.h>
>
> uint64_t read64bits(const void * p) {
>     uint64_t x;
>     memcpy((void*) &x, p, sizeof(uint64_t));
>     return x;
> }

Now you're arguing against yourself again.

That means that whatever I respond, I can expect a random direction answer.

Anyway:

* The C style cast there is both unnecessary and dangerous, because it
can cast away const, and is difficult to grep, so it's ungood code.
* You're wrong about formally no padding bits for C++, so in principle
that function can produce an invalid `uint64` with trap representation;
that's UB -- except that that's in principle, not in practice.
* If the pointer `p` is invalid, or is a nullpointer, or doesn't point
to at least sizeof(uint64_t) contiguous bytes of readable memory, then
that's UB, and it's UB both in principle and in practice.

If you had been a certain other old timer in this group, then it would
also be relevant that there's possible UB due to stack overflow.

Which by his (lack of) logic leads to the conclusion that all C++
programs have UB.

> We can assume that "p" points to data of some type of at least 64 bits
> in size.  I would like to hear of any potential issues in C or C++
> (hence the cross-language code).

Oh, cross language, sorry.

For the case of C /I believe/ that there's a formal guarantee of no
padding bits, so then only the last point above matters wrt. UB.

>> I'm not sure if you're addressing only the formal here.
>
> No.  It is a general principle.  Some people /do/ believe that "separate
> compilation" creates magical barriers that limit a compiler's ability to
> see the relationships between code sections, and therefore its ability
> to "optimise using assumptions about defined and undefined behaviours",
> and that this means some kinds of undefined behaviours become defined by
> moving code to a different file or disabling optimisation.  They are
> wrong to believe this.  They may manage to write code that works when
> they test it, but it will be fragile - the code still has exactly the
> same undefined behaviours, and these may manifest as bugs in the future.
>
>>
>> However, if you intended this to also apply to the in-practice, then
>> the burden of proof is on you that some computer exists where
>> `uint64_t` has bits that do not participate in the value
>> representation, so that they /can/ be invalid: as far as I know there
>> is no such computer.
>>
>
> No, not at all.  It is only /you/ that has suggested, by claiming the
> use of memcpy is not fully defined, that uint64_t may hypothetically
> contain padding bits.  (See earlier in my reply.)  I know it can't, so
> that is not the issue.

Now you're claiming that your argument was my argument. Jeez.

[snip]

- Alf

On 16/06/2023 16:12, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/06/2023 12:34, Alf P. Steinbach wrote:
>>> On 2023-06-16 10:55 AM, David Brown wrote:
>>>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>>>
>>>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>>>
>>>>
>>>> I don't know how the function here is supposed to be used.  We know that
>>>> the pointer (it is syntactically a reference, but effectively a pointer)
>>>> is properly aligned for a uint64_t, but we don't know if it actually
>>>> points to a uint64_t.  Perhaps it points to a double, or some other
>>>> 64-bit type.
>>> In the case you sketch where the bits do not represent a valid
>>> `uint64_t`, the `memcpy` does not make the behavior well-defined: that's
>>> a (dangerous) misconception.
>>
>> A "uint64_t" has a guaranteed fully-defined format and no padding bits. All
>> possible bit patterns for the type have well-defined
>> behaviour.
>
> "Fully-defined format" says, to my mind, more that you wanted to say.
> In particular the significance of the bits is not defined.

The order of the bits is implementation-defined, and the bits are
required to represent different powers of two from 0 to 63. There can
be no padding bits.

I was using "fully defined" to mean "defined by the standard or
implementation defined" - i.e., something documented that you could rely
upon. (I should have made that clear.)

It is certainly allowed for an implementation to have different
endianness for different types - so even if "double" uses the IEEE
formats, storing a value as a double and reading it as a uint64_t may
have different results on different platforms. I suspect such
inconsistently ordered implementations would be quite rare, however -
usually the bit ordering is either clearly little-endian or clearly
big-endian.

>
>> (Hypothetically, that would not be true for "unsigned long
>> long", which could contain padding bits and have could have trap
>> representations.)
>>
>> In case I am missing something, please tell me where you see any possible
>> dangerous or not fully defined behaviour even for the more general case :
>>
>> #include <string.h>
>> #include <stdint.h>
>>
>> uint64_t read64bits(const void * p) {
>> uint64_t x;
>> memcpy((void*) &x, p, sizeof(uint64_t));
>> return x;
>> }
>
> What's not "fully defined behaviour" is the return value's relationship
> to the bytes pointed to by p.
> I think you are using "fully defined
> behaviour" to mean "not undefined behaviour", but since the former is
> not a technical term in the language standards, a reader might take more
> from it than you intended.
>
> Yes, this is something of a nit-pick, I know.
>

I am interested in nit-picks, and glad to hear of any you find.

If I had written "standards-defined and/or implementation defined
behaviour" instead of "fully defined behaviour", would that be sufficient?

On 16/06/2023 17:25, Alf P. Steinbach wrote:
> On 2023-06-16 2:55 PM, David Brown wrote:
>> On 16/06/2023 12:34, Alf P. Steinbach wrote:
>>> On 2023-06-16 10:55 AM, David Brown wrote:
>>>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>>>
>>>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>>>
>>>> I don't know how the function here is supposed to be used.  We know
>>>> that the pointer (it is syntactically a reference, but effectively a
>>>> pointer) is properly aligned for a uint64_t, but we don't know if it
>>>> actually points to a uint64_t.  Perhaps it points to a double, or
>>>> some other 64-bit type.
>>>
>>> In the case you sketch where the bits do not represent a valid
>>> `uint64_t`, the `memcpy` does not make the behavior well-defined:
>>> that's a (dangerous) misconception.
>>
>> A "uint64_t" has a guaranteed fully-defined format and no padding bits.
>
> Since you believe that,

Ref. C standards 7.20.1.1p2, 6.2.6.1p2, 6.2.6.2p1.

I believe the C++ standards inherit this from C, and the C standards are
easier to reference (IMHO) because the numbering stays consistent
between versions.

> your comment about "Perhaps points to a double"
> is meaningless nonsense.

I'm sorry, I have no idea what you mean by that.

>
> You're arguing against yourself, with only three lines between your two
> comments that are shooting dum-dum bullets at each other.
>
> Make up your mind, please.

Again, I have no idea what you mean.

Perhaps you don't remember what you wrote yourself?

>
>
>> All possible bit patterns for the type have well-defined behaviour.
>> (Hypothetically, that would not be true for "unsigned long long",
>> which could contain padding bits and have could have trap
>> representations.)
>
> We could discuss this assertion, e.g. I could helpfully mention that in
> C++ "these requirements do not hold for other types [than character
> types]", but better that you waste time attempting to PROVE IT.
>
> Chapter and verse, please.
>

The C++ standards change their numbering regularly. These numbers are
from the C++20 draft N4860 - I don't believe the contents change much
between versions.

6.8.1p3 .. p5 describes the representation of unsigned types as
collections of bits representing powers of 2. For unsigned integer
types in general, there may be padding bits, but there are no padding
bits in char, signed char, unsigned char and char8_t. (C defines the
bit order for unsigned char, but I don't think C++ does as far as I can
see.)

17.4.1 specifies <cstdint>, and in 17.4.1p2 this refers back to the C
standards section 7.20 where the size-specific integer types are defined
to have no padding bits.

So again - please tell me why you think memcpy'ing data into a uint64_t
may have dangerous or poorly defined behaviour.

The ball is in your court.

> Not that it matters for what I've written, but it matters for the silly
> argument that you offered, quoted above, and that you now argue against,
> plus, there is the thing about being Wrong on the internet, not to
> mention Doubly Wrong: just on principle one should not let that pass.
>
>
>> In case I am missing something, please tell me where you see any
>> possible dangerous or not fully defined behaviour even for the more
>> general case :
>>
>> #include <string.h>
>> #include <stdint.h>
>>
>> uint64_t read64bits(const void * p) {
>>      uint64_t x;
>>      memcpy((void*) &x, p, sizeof(uint64_t));
>>      return x;
>> }
>
> Now you're arguing against yourself again.
>
> That means that whatever I respond, I can expect a random direction answer.
>
> Anyway:
>
> * The C style cast there is both unnecessary and dangerous, because it
> can cast away const, and is difficult to grep, so it's ungood code.

I am asking what you think is /dangerous/ or not fully defined here -
not whether there might be an unnecessary cast or whether the style is
"perfect" according to your questionable judgement.

> * You're wrong about formally no padding bits for C++, so in principle
> that function can produce an invalid `uint64` with trap representation;
> that's UB -- except that that's in principle, not in practice.

See above for the chapter and verse you requested.

> * If the pointer `p` is invalid, or is a nullpointer, or doesn't point
> to at least sizeof(uint64_t) contiguous bytes of readable memory, then
> that's UB, and it's UB both in principle and in practice.
>

See below for the explicit assumption that p points to sufficient
readable data.

> If you had been a certain other old timer in this group, then it would
> also be relevant that there's possible UB due to stack overflow.
>
> Which by his (lack of) logic leads to the conclusion that all C++
> programs have UB.
>

I hope we can agree to assume that kind of thing is outside the scope of
the language!

>
>> We can assume that "p" points to data of some type of at least 64 bits
>> in size.  I would like to hear of any potential issues in C or C++
>> (hence the cross-language code).
>
> Oh, cross language, sorry.

No problem. As long as we avoid crass language :-)

>
> For the case of C /I believe/ that there's a formal guarantee of no
> padding bits, so then only the last point above matters wrt. UB.
>

Ah ha - now we are getting somewhere!

I suspect the key point is that the C++ standard does not explicitly
define uint64_t to have no padding bits, but it refers to the C standard
which /does/ have such guarantees. C++ inherits them from C.

>
>>> I'm not sure if you're addressing only the formal here.
>>
>> No.  It is a general principle.  Some people /do/ believe that
>> "separate compilation" creates magical barriers that limit a
>> compiler's ability to see the relationships between code sections, and
>> therefore its ability to "optimise using assumptions about defined and
>> undefined behaviours", and that this means some kinds of undefined
>> behaviours become defined by moving code to a different file or
>> disabling optimisation.  They are wrong to believe this.  They may
>> manage to write code that works when they test it, but it will be
>> fragile - the code still has exactly the same undefined behaviours,
>> and these may manifest as bugs in the future.
>>
>>>
>>> However, if you intended this to also apply to the in-practice, then
>>> the burden of proof is on you that some computer exists where
>>> `uint64_t` has bits that do not participate in the value
>>> representation, so that they /can/ be invalid: as far as I know there
>>> is no such computer.
>>>
>>
>> No, not at all.  It is only /you/ that has suggested, by claiming the
>> use of memcpy is not fully defined, that uint64_t may hypothetically
>> contain padding bits.  (See earlier in my reply.)  I know it can't, so
>> that is not the issue.
>
> Now you're claiming that your argument was my argument. Jeez.
>

Please re-read your reply to Bonita. You were advocating using
separately compiled code so that you can use assignment instead of
memcpy - claiming, bizarrely, that assignment was "safe" and memcpy
"unsafe" despite insisting on separately compiled functions for your
"solution" to work "in practice".

And then you claimed that the memcpy version was not well defined.

On 2023-06-16 6:32 PM, David Brown wrote:
[snip]
>>>
>>> A "uint64_t" has a guaranteed fully-defined format and no padding bits.
[snip]
> The C++ standards change their numbering regularly.  These numbers are
> from the C++20 draft N4860 - I don't believe the contents change much
> between versions.
>
> 6.8.1p3 .. p5 describes the representation of unsigned types as
> collections of bits representing powers of 2.  For unsigned integer
> types in general, there may be padding bits, but there are no padding
> bits in char, signed char, unsigned char and char8_t.

[snip]

> The ball is in your court.

In the above you contradict yourself:

* First you claim that there are no padding bits for `uint64_t`.
* Then you paraphrase the standard that "there may be padding bits".

---

I elected now to not quote or respond to the rest which likewise
involved some self-contradictions.

- Alf

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 2023-06-16 10:55 AM, David Brown wrote:
>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>
>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>
>> I don't know how the function here is supposed to be used.  We know
>> that the pointer (it is syntactically a reference, but effectively a
>> pointer) is properly aligned for a uint64_t, but we don't know if it
>> actually points to a uint64_t.  Perhaps it points to a double, or
>> some other 64-bit type.
>
> In the case you sketch where the bits do not represent a valid
> `uint64_t`, the `memcpy` does not make the behavior well-defined:
> that's a (dangerous) misconception.

I think David was suggesting, not the bits are not a valid
representation for an object of type uint64_t, but that for example the
pointer point to an object whose type is, say, double. (I haven't
followed the discussion closely enough to have an opinion on whether
that matters.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
> On 2023-06-15 12:27 AM, James Kuyper wrote:
> > On 6/14/23 15:46, Alf P. Steinbach wrote:
....
> > All you need is a platform where misaligned pointers do not merely cause
> > the code to be inefficient, but to actually malfunction. On such a
> > platform, if p_bytes is not correctly aligned to store a uint64_t, then
> > the code will malfunction in the reinterpret_cast<>.
> Yes, but irrelevant for the case discussed, because the values are
> guaranteed correctly aligned.

You said nothing about what p_bytes was when you asked

"how is the compiler to know that it's generally called with a
`*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"

In particular, you said nothing about p_bytes that would guarantee that it was
correctly aligned. The memcpy() would only be reasonable if it were possible
for "data' to be a misaligned pointer; otherwise simple assignment would be
simpler and equally safe.

> [snip]
> > If p_bytes is correctly aligned, simple assignment will work just as
> > well as memcpy().
> Yes.
> >> Even g++'s documentation of `-fstrict-aliasing` says "A character type
> >> may alias any other type.". ...
> >
> > True, but that's not what this reinterpret_cast does;
> It is what this `reinterpret_cast` does.

This reinterpret_cast converts p_bytes, which presumably points to the
first element of an array of character type, into a pointer to uint64_t*. In
other words, an array of char is being aliased as a uint64_t. Are you
claiming that uint64_t is a character type?

On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
> ...
>>> All you need is a platform where misaligned pointers do not merely cause
>>> the code to be inefficient, but to actually malfunction. On such a
>>> platform, if p_bytes is not correctly aligned to store a uint64_t, then
>>> the code will malfunction in the reinterpret_cast<>.
>> Yes, but irrelevant for the case discussed, because the values are
>> guaranteed correctly aligned.
>
> You said nothing about what p_bytes was when you asked
>
> "how is the compiler to know that it's generally called with a
> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>
> In particular, you said nothing about p_bytes that would guarantee that it was
> correctly aligned.

That was known from the optimization attempt in the original posting's
code (I'm not the OP):

#if defined(__GNUC__) || defined(__llvm__)
if( (size_t)&data % 8 )
__builtin_unreachable();
#endif

> The memcpy() would only be reasonable if it were possible
> for "data' to be a misaligned pointer; otherwise simple assignment would be
> simpler and equally safe.

On that we agree. :)

>> [snip]
>>> If p_bytes is correctly aligned, simple assignment will work just as
>>> well as memcpy().
>> Yes.
>>>> Even g++'s documentation of `-fstrict-aliasing` says "A character type
>>>> may alias any other type.". ...
>>>
>>> True, but that's not what this reinterpret_cast does;
>> It is what this `reinterpret_cast` does.
>
> This reinterpret_cast converts p_bytes, which presumably points to the
> first element of an array of character type, into a pointer to uint64_t*. In
> other words, an array of char is being aliased as a uint64_t. Are you
> claiming that uint64_t is a character type?

It may be that my English isn't good enough to understand a one-way
nature of the GCC docs' wording.

Perhaps.

The way I think, aliasing is of interest to the compiler because where
it can assume that a T value is never changed via a U* pointer, and that
the value that the U* points to is never changed by a change to the T
value, it can optimize, e.g. not reload that value from memory when it's
already in a register. If T = float and U* = int*, then it can make this
assumption. Similarly if T = int and U* = float*, it can assume this.

But if T = char-type, such as the first char in an array, and U* is a
double*, then it can not reasonably make this assumption, and as I read
the docs quote g++ doesn't make this assumption for T = char-type.

And similarly, if T = double and U* is a char-type*, then it can not
reasonably make this assumption, and as I read the docs quote g++
doesn't make this assumption for U* = char-type*.

That is, as I read it, based more on reasoning about the purpose than
expertise in English (I'm Norwegian), the wording works both ways.
char-type on either side is OK. But invoking that freedom twice with
different types, to end up with e.g. int* and double* pointers that are
the same address, so that an int assignment can change a double or vice
versa, is ungood.

- Alf

On 17/06/2023 00:17, Alf P. Steinbach wrote:
> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>> ...
>>>> All you need is a platform where misaligned pointers do not merely
>>>> cause
>>>> the code to be inefficient, but to actually malfunction. On such a
>>>> platform, if p_bytes is not correctly aligned to store a uint64_t, then
>>>> the code will malfunction in the reinterpret_cast<>.
>>> Yes, but irrelevant for the case discussed, because the values are
>>> guaranteed correctly aligned.
>>
>> You said nothing about what p_bytes was when you asked
>>
>> "how is the compiler to know that it's generally called with a
>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>
>> In particular, you said nothing about p_bytes that would guarantee
>> that it was
>> correctly aligned.
>
> That was known from the optimization attempt in the original posting's
> code (I'm not the OP):
>
>     #if defined(__GNUC__) || defined(__llvm__)
>         if( (size_t)&data % 8 )
>             __builtin_unreachable();
>     #endif
>
>
>> The memcpy() would only be reasonable if it were possible
>> for "data' to be a misaligned pointer; otherwise simple assignment
>> would be
>> simpler and equally safe.
>
> On that we agree. :)

If we knew that the original pointer pointed to a uint64_t, then we
could /all/ agree that a plain assignment would be simpler, clearer, and
as efficient as possible.

But as far as I know, no such guarantee exists. My guess, from how
functions like this are sometimes used, is that the original data is in
an array of unsigned char - perhaps a buffer for a received network
packet or a file that has been read.

And if the data does not start as a uint64_t (or compatible type), then
reading it through a uint64_t glvalue is /not/ safe, even if alignment
is guaranteed.

>
>
>>> [snip]
>>>> If p_bytes is correctly aligned, simple assignment will work just as
>>>> well as memcpy().
>>> Yes.
>>>>> Even g++'s documentation of `-fstrict-aliasing` says "A character type
>>>>> may alias any other type.". ...
>>>>
>>>> True, but that's not what this reinterpret_cast does;
>>> It is what this `reinterpret_cast` does.
>>
>> This reinterpret_cast converts p_bytes, which presumably points to the
>> first element of an array of character type, into a pointer to
>> uint64_t*. In
>> other words, an array of char is being aliased as a uint64_t. Are you
>> claiming that uint64_t is a character type?
>
> It may be that my English isn't good enough to understand a one-way
> nature of the GCC docs' wording.
>

The "cppreference" site is often clearer than the standards language:

<https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>

The key point is that a reinterpret_cast (or equivalent via a C-style
cast) does not let you access incompatible types. It does not, in gcc
parlance, side-step the strict aliasing rules.

Like a C cast, reinterpret_cast is a way to tell the compiler that you
think it is safe to change the type of an object (usually a pointer).
But it does not /make/ it safe. And if the compiler can see that the
actual object type is not compatible with the way you are accessing it,
then you have a conflict - you are lying to the compiler, and no good
will come of it. A reinterpret_cast will not change that situation.
(And separate compilation will only hide the problem.)

> Perhaps.
>
> The way I think, aliasing is of interest to the compiler because where
> it can assume that a T value is never changed via a U* pointer, and that
> the value that the U* points to is never changed by a change to the T
> value, it can optimize, e.g. not reload that value from memory when it's
> already in a register. If T = float and U* = int*, then it can make this
> assumption. Similarly if T = int and U* = float*, it can assume this.
>

Yes.

> But if T = char-type, such as the first char in an array, and U* is a
> double*, then it can not reasonably make this assumption, and as I read
> the docs quote g++ doesn't make this assumption for T = char-type.
>

No. You can use a char-type pointer to access a non-char object, but
you cannot use a non-char pointer to access a char (array) object.

I think gcc's documentation could certainly be clearer here, and I also
think that the documentation for "-fstrict-aliasing" flag could be moved
from an optimisation flag to the "code generation options" page. IMHO,
using "-fno-strict-aliasing" is a significant change to the semantics of
the language, making previously undefined behaviour into defined
behaviour (much like "-fwrapv" does for signed integer overflow).

> And similarly, if T = double and U* is a char-type*, then it can not
> reasonably make this assumption, and as I read the docs quote g++
> doesn't make this assumption for U* = char-type*.
>

Correct.

However, gcc/g++ is not saying anything more or less than the standards
say here. The behaviour - both the defined behaviour, and the undefined
behaviour - comes straight from the standard. (The only exception is
for type-punning unions. C90 did not explicitly say they were allowed,
but the gcc documentation says they are allowed even in C90 mode. C99
onwards allows them, while C++ never has.)

> That is, as I read it, based more on reasoning about the purpose than
> expertise in English (I'm Norwegian), the wording works both ways.
> char-type on either side is OK. But invoking that freedom twice with
> different types, to end up with e.g. int* and double* pointers that are
> the same address, so that an int assignment can change a double or vice
> versa, is ungood.
>
>
> - Alf
>