Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 12 Sep 2024 06:17:24 -0700
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <86ttelf1uj.fsf@linuxsc.com>
References: <vaqgtl$3526$1@dont-email.me> <memo.20240830090549.19028u@jgd.cix.co.uk> <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com> <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z> <2024Sep11.123824@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Thu, 12 Sep 2024 15:17:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="62297a80a79ef9d9a88587ce28522bc2";
	logging-data="297610"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+zfgYzIiClENaCsaxR6zh2KGcLLNhJ1VE="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:mG/uOsORtYJjaYoD9rCFHxpG2p8=
	sha1:nMMg+Kf/XmV2R4tm7s71g81bGIc=
Bytes: 3439

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().