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: Tue, 10 Sep 2024 11:49:03 +0300
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <20240910114903.00003fff@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 10 Sep 2024 10:48:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f724e564b9b82ba3394a62309ea0ddd4";
	logging-data="2041887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/UTRyLEGIegwo1f5eNiBwVU8QOp0XWw7o="
Cancel-Lock: sha1:otWFWZYUIIItfZ3mlY0E0qbhtVw=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2377

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.