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:21:01 +0300
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <20240910112101.00006002@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>
	<p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 10 Sep 2024 10:20:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f724e564b9b82ba3394a62309ea0ddd4";
	logging-data="2041887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18BRGwiyxQ20FUl2AsC/qmTyf8QzAx0LEk="
Cancel-Lock: sha1:qvkyREONSSG2fJuLwzKQalkfWCM=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3033

On Mon, 09 Sep 2024 23:27:24 -0400
George Neuner <gneuner2@comcast.net> wrote:

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

According to my understanding, your 'can be considered' part is not
codified in the C Standard.

> Adding size_t to a pointer yields another pointer of the same type.
> 
> 
> All of gcc, clang and MSVC seem happy with this.
>

It works. But is it guaranteed to work in the future by some sort of
document? I am pretty sure that no such guarantee exists in gcc and
MSVC docs. I did not look in clang docs. Trying to find anythings in
LLVM/clang docs makes me sad.