Re: Computer architects leaving Intel...

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

Michael S <already5chosen@yahoo.com> writes:
>

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 check that reliably catches all overlaps seems easy.
E.g. (src <= dst) == (src+len > dst)
>
In theory, on unusual hardware platform it can give false positives.
May be, for task in hand that's o.k.

>
The challenge is to find portable C that doesn't enter the arena
of undefined behavior (and also detects exactly those cases where
overlap occurs), and that is quite a stringent criterion.
>
The comparison shown works if src and dst both point to elements
of the same array.  [...]

Sorry, that statement isn't right.  I accepted the stated test as
being accurate without checking it myself.  My bad. :)