Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 09 Sep 2024 07:40:38 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 63
Message-ID: <2024Sep9.094038@mips.complang.tuwien.ac.at>
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> <86y141js89.fsf@linuxsc.com>
Injection-Date: Mon, 09 Sep 2024 10:02:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bff24d76364ca7ea0d223f91191d43fd";
	logging-data="2463772"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19LIw3V9zaAwMmF62XO1dLE"
Cancel-Lock: sha1:dERFaPlrZsyJE1A/dsij8yMvQ0g=
X-newsreader: xrn 10.11
Bytes: 3792

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> 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;
>
>Yes, I can.
>
>> 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?
>
>Sure.  I wouldn't have made my earlier statement otherwise.

You also stated "I'm confident the people who wrote the C standard
would say such a program is strictly conforming." about a program with
implementation-defined behaviour, so I lack confidence in your claim.

>> 2) Even if there is such a check, you have to be aware that there
>> is a potential problem with memcpy().  In that case the way to go
>> is to just use memmove().
>
>The point of my previous comment was only to address the question
>of whether any existing memcpy() calls are problematic.  If all
>of the checks return "no overlap" then memcpy() is not the problem.

At least for the test runs.

>> But that does not help you with the next "clever" idea that some
>> compiler or library maintainer has.
>
>I have the impression that this is an editorial comment having
>nothing to do with memcpy() or memmove().  If that impression
>is wrong then I'm at a loss to understand what you are talking
>about, and would you please elaborate.

There are at least 200 undefined behaviours in the C standard, and
according to some people, C programmers should avoid all of them.  So
the possible breakage of memcpy() is just one of many problems that
the programmers should be aware of and that they should test for.

Just because we discussed memcpy() as one of the problems with this
approach does not mean that having a way to deal with memcpy() solves
the larger problem.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>