Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 11 Sep 2024 14:51:16 +0300
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <20240911145116.00000fa0@yahoo.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>
	<vbrtll$3ip2f$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 Sep 2024 13:50:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="baae2efd373f56ca301a1cba6c5c3943";
	logging-data="3668175"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/WETJCj/w0nMqc7Cm/XqdgN7mxQHt2xoE="
Cancel-Lock: sha1:xpl0xl6MhalU8ceVk067TrPH4CI=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2756

On Wed, 11 Sep 2024 13:07:33 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Tim Rentsch wrote:
> > 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)  
> 
> Does that work for dst < src? What if dst+len < src?
> 

No, it doesn't. See the followup post.