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

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

Path: ...!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: Tue, 10 Sep 2024 15:30:26 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 41
Message-ID: <2024Sep10.173026@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> <20240910114903.00003fff@yahoo.com>
Injection-Date: Tue, 10 Sep 2024 17:42:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f21f15281580639cd9bc25764f54f587";
	logging-data="3185537"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fdPc9uMt+aQpaLthcuJwN"
Cancel-Lock: sha1:90qKExmK1WlItIcZPEW9ut29gJQ=
X-newsreader: xrn 10.11
Bytes: 2905

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

That is probably the original motivation for that lack of definition
(e.g., compare only the offset on large-model 8086).

However, if the compiler ATUBDNH, that assumption can lead to the
"knowledge" that src and dest point into the same object, and that may
produce unintended results beyond false positives on some hardware
platforms.

I have not heard about a C compiler that has this misfeature, but I
would not be surprised if it shows up at some point (hopefully with
some flag to define the ordering of pointers to different objects).

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