Deutsch   English   Français   Italiano  
<2024Sep8.173639@mips.complang.tuwien.ac.at>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.nobody.at!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: Sun, 08 Sep 2024 15:36:39 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 28
Message-ID: <2024Sep8.173639@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>
Injection-Date: Sun, 08 Sep 2024 17:49:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d5e623bbaa085cebf149e53e66f130a5";
	logging-data="2078153"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ZF2gWhLuVWgNMtkT1G+PU"
Cancel-Lock: sha1:Bj4tdfi5DefA79Ptc9MMomCg41g=
X-newsreader: xrn 10.11
Bytes: 2325

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?

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().  But that does not help you with the next "clever"
idea that some compiler or library maintainer has.

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