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: Wed, 11 Sep 2024 08:07:34 -0700
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <86seu6grex.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> <20240910114903.00003fff@yahoo.com> <861q1ring8.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 11 Sep 2024 17:07:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6270473d9727e24675cb7c993eb45a62";
	logging-data="3859491"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19JxVM6xHx2uAY5AU/7N0VA0wSgzv5rsZc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:po5ZDEJI3D6dOyHIOfpXda7R2aU=
	sha1:ZL6UPpE3fS1+/lVPoQW8RSsmKH8=
Bytes: 3000

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