Liste des Groupes | Revenir à c arch |
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.
>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;
None of the compilers at godbolt seem to need this to compare
arbitrary addresses as char*, but all accept it.
Obviously speculation, but it's the best I have.
Les messages affichés proviennent d'usenet.