Re: Computer architects leaving Intel...

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

Josh Vanderhoof <x@y.z> writes:
>

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

George Neuner <gneuner2@comcast.net> writes:
>

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

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?

>
...
>

It is legal to test for equality between pointers to different
objects so you could test for overlap by testing against every
element in the array.  It seems like it should be possible for the
compiler to figure out what's happening and optimize those tests
away, but unfortunately no compiler I tested did it.

>
That would be an interesting result of the ATUBDNH lunacy:
programmers would see themselves forced to write workarounds such
as the one you suggest (with terrible performance when not
optimized), and then C compiler maintainers would see themselves
forced to optimize this kind of code.  The end result would be
that both parties have to put in more effort to eventually get the
same result as if ordered comparison between different objects had
been defined from the start.
>
For now, the ATUBDNH advocates tell programmers that they have to
work around the lack of definition, but there is usually no
optimization for that.

This reaction doesn't fit the case here.  The C standard already
provides a way to do what is needed, namely memmove().  The code
being discussed in this thread is relevant only because someone
(may have) wrongly used memcpy() rather than memmove().  As has
been pointed out, all of the worries around this problem can be
avoided by simply using memmove() rather then memcpy().