Re: Computer architects leaving Intel...

George Neuner <gneuner2@comcast.net> writes:

On Tue, 10 Sep 2024 11:21:01 +0300, Michael S
<already5chosen@yahoo.com> wrote:
>

On Mon, 09 Sep 2024 23:27:24 -0400
George Neuner <gneuner2@comcast.net> wrote:
>

On Sun, 08 Sep 2024 15:36:39 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:
>

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>

There was still no easy way to determine whether your software
that calls memcpy() actually works as expected on all hardware,

>
There may not be a way to tell if memcpy()-calling code will
work on platforms one doesn't have, but there is a relatively
simple and portable way to tell if some memcpy() call crosses
over into the realm of undefined behavior.

>
1) At first I thought that yes, one could just check whether
there is an overlap of the memory areas.  But then I remembered
that you cannot write such a check in standard C without (in the
general case) exercising undefined behaviour;  and then the
compiler could eliminate the check or do something else that's
unexpected.  Do you have such a check in mind that does not
exercise undefined behaviour in the general case?

>
The result of comparing pointers to two elements of the same array
is defined.  Cast to (char*), both src and dst can be considered
to point to elements of the [address space sized] char array at
address zero.

>
According to my understanding, your 'can be considered' part is not
codified in the C Standard.
>

Adding size_t to a pointer yields another pointer of the same
type.

In terms of types, that is right, but the addition works only if
the pointer points into an array large enough to include the
result of the addition (the result is also allowed to be just one
past the end of the array).

All of gcc, clang and MSVC seem happy with this.

>
It works.  But is it guaranteed to work in the future by some sort
of document?  I am pretty sure that no such guarantee exists in gcc
and MSVC docs.  I did not look in clang docs.  Trying to find
anythings in LLVM/clang docs makes me sad.

>
I know that it has worked as expected with every version of gcc
and Microsoft I've used since 1988.  [clang I don't use, but I
tried it on godbolt.org with the most recent version]
>
Will it continue to work ... who knows?
>
>
I definitely am NOT an expert on the C standard, but thinking
about it, it occurred to me that if an array is explicitly defined
that *might* cover all memory (or at least all heap), then the
compiler would have to honor any apparent pointers into it.
>
E.g., char (*all_memory)[] = 0;

This declaration introduces a pointer, not an array.  Similarly
the declaration

    char (*great_white_array)[ 999999999999999999 ] = 0;

does not introduce an array but just a pointer (and initializes
the pointer to be a null pointer).  There is no humongous array.

None of the compilers at godbolt seem to need this to compare
arbitrary addresses as char*, but all accept it.

The given declaration of 'all_memory' is strictly conforming.
It must be accepted by any conforming C implementation (which
all of gcc, clang, and MSVC purport to be, IIUC).

Obviously speculation, but it's the best I have.

It's important to realize that there are two distinct questions.
One, does the code work (in a given implementation)?  Two, does
the code satisfy the rules given in the C standard?

Unfortunately having an answer to the first question does not by
itself give enough information to answer the second question.