Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Thu, 12 Sep 2024 04:04:06 -0700 Organization: A noiseless patient Spider Lines: 91 Message-ID: <8634m5gml5.fsf@linuxsc.com> References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <20240910112101.00006002@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 12 Sep 2024 13:04:11 +0200 (CEST) Injection-Info: dont-email.me; posting-host="62297a80a79ef9d9a88587ce28522bc2"; logging-data="249101"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZHX0t3ZYdpyCDfcq3zPS/STHTBcQm7G4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:697NkAqk5DJMoMcPFw+SCz1sq1E= sha1:Op1mawEutdFlj4nyTip5/UKzfU8= Bytes: 5077 George Neuner writes: > On Tue, 10 Sep 2024 11:21:01 +0300, Michael S > wrote: > >> On Mon, 09 Sep 2024 23:27:24 -0400 >> George Neuner wrote: >> >>> On Sun, 08 Sep 2024 15:36:39 GMT, anton@mips.complang.tuwien.ac.at >>> (Anton Ertl) wrote: >>> >>>> Tim Rentsch 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. In terms of types, that is right, but the addition works only if the pointer points into an array large enough to include the result of the addition (the result is also allowed to be just one past the end of the array). >>> 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. > > I know that it has worked as expected with every version of gcc > and Microsoft I've used since 1988. [clang I don't use, but I > tried it on godbolt.org with the most recent version] > > Will it continue to work ... who knows? > > > I definitely am NOT an expert on the C standard, but thinking > about it, it occurred to me that if an array is explicitly defined > that *might* cover all memory (or at least all heap), then the > compiler would have to honor any apparent pointers into it. > > E.g., char (*all_memory)[] = 0; This declaration introduces a pointer, not an array. Similarly the declaration char (*great_white_array)[ 999999999999999999 ] = 0; does not introduce an array but just a pointer (and initializes the pointer to be a null pointer). There is no humongous array. > None of the compilers at godbolt seem to need this to compare > arbitrary addresses as char*, but all accept it. The given declaration of 'all_memory' is strictly conforming. It must be accepted by any conforming C implementation (which all of gcc, clang, and MSVC purport to be, IIUC). > Obviously speculation, but it's the best I have. It's important to realize that there are two distinct questions. One, does the code work (in a given implementation)? Two, does the code satisfy the rules given in the C standard? Unfortunately having an answer to the first question does not by itself give enough information to answer the second question.