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: Tue, 10 Sep 2024 08:19:32 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 37
Message-ID: <2024Sep10.101932@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> <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
Injection-Date: Tue, 10 Sep 2024 10:33:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f21f15281580639cd9bc25764f54f587";
	logging-data="2997940"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+aELIzUhU96DPziQrIp7jU"
Cancel-Lock: sha1:Fmd0Wb73336AYSRc7iqlFWoEtfI=
X-newsreader: xrn 10.11
Bytes: 2927

George Neuner <gneuner2@comcast.net> writes:
>On Sun, 08 Sep 2024 15:36:39 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>>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 result of comparing pointers to two elements of the same array is
>defined.  Cast to (char*), both src and dst can be considered to point
>to elements of the [address space sized] char array at address zero.

Yes, that would be reasonable.  Unfortunately, "optimizations" that
assume that undefined behaviour does not happen are not justified by
assigning reasonable meaning to language constructs, but by giving
only the little meaning to language constructs that the standard
requires, and in case of unequality comparisons between pointers to
different objects, the C standard does not define a meaning for that.

>All of gcc, clang and MSVC seem happy with this.

But the next version of gcc or clang might see such a check and decide
to bite you.

One can cast the pointers into an uintptr_t, and try to do the check
there.  AFAIK the result would be implementation-defined, but on an
architecture with a flat address space it's unlikely that they will
find a way to compile the code in a different way than the programmer
intended without making "relevant" programs slower.

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