Liste des Groupes | Revenir à c arch |
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.
Les messages affichés proviennent d'usenet.