Path: ...!feeds.phibee-telecom.net!news.mixmin.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: Mon, 02 Sep 2024 10:21:17 -0700 Organization: A noiseless patient Spider Lines: 103 Message-ID: <86r0a2otte.fsf@linuxsc.com> References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <2024Aug30.195831@mips.complang.tuwien.ac.at> <2024Aug31.170347@mips.complang.tuwien.ac.at> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org> <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 02 Sep 2024 19:21:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="8d0da47a40f6e375f3916ecef59d9608"; logging-data="3089842"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+4vm1VH1aH8Zs0HRrmlRkO9AGnG1t/dwo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Sni5VVys8GEsWtkTpTPEwwRfzEY= sha1:mi9/AEEfOw0RW4IYXpxnD+w0Zzg= Bytes: 6374 Michael S writes: > On Mon, 02 Sep 2024 06:59:32 -0700 > Tim Rentsch wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >> >>> On Mon, 2 Sep 2024 5:55:34 +0000, Thomas Koenig wrote: >>> >>>> George Neuner schrieb: >>>> >>>>> I'm not going to argue about whether UB in code is wrong. The >>>>> question I have concerns what to do with something that >>>>> explicitly is mentioned as UB in some standard N, but was not >>>>> addressed in previous standards. >>>>> >>>>> Was it always UB? Or should it be considered ID until it became >>>>> UB? >>>> >>>> Can you give an exapmple? >>> >>> Memcopy() with overlapping pointers. >> >> Calling memcpy() between objects that overlap has always been >> explicitly and specifically undefined behavior, going back to >> the original ANSI C standard. > > 3 years ago Terje Mathisen wrote that many years ago he read that > behaviour of memcpy() with overlappped src/dst was defined. > https://groups.google.com/g/comp.arch/c/rSk8c7Urd_Y/m/ZWEG5V1KAQAJ > Mitch Alsup answered "That was true in 1983". > So, two people of different age living in different parts of the world > are telling the same story. May be, there exist old popular book that > said that it was defined? My first answer is that the question asked was about standards, and that is the question I was answering. There were no C standards before 1989. My second answer is, if I wanted to research the issue for the time before there were any C standards, I would start with these references, in more or less this order: K&R original edition (1978) PJ Plauger's book on implementing the C standard library Harbison and Steele K&R 2nd edition (1988?) Probably there are others but these are what I thought of off the top of my head. My third answer is, it wouldn't surprise me if there were a book or some sort of reference document that makes such a claim about how memcpy behaves, but I'm not aware of any (which doesn't mean anything), and nothing comes to mind in the general domain of near-authoritative books on C (other than the four listed above). So, assuming there is such a book or document, I expect it would be one of two things: Reference documentation for some specific C implementation (as for example from Sun Microsystems); or A book (or document) that purports to be authoritative (or maybe appears to be authoritative) but in reality is not. Obviously I can't disprove the existence of something that Terje said he read many years ago (perhaps with more information this could be done, but for sure I don't have such information). For the sake of discussion I'm willing to stipulate that Terje did read something and that what he read did say something about memcpy working for overlapping arguments. The question then becomes, What is it that he read, and what exactly did it say? I'm not in a position to answer those questions but maybe Terje or someone else remembers and can fill us in. (My aversion to using google groups stops me from following the reference you nicely provided.) To all this I should add that it certainly is feasible to implement memcpy so that it works with overlapping arguments, and I have no doubt (strictly speaking, less than epsilon doubt) that some library implementer somewhere (and probably more than one) has done this. Also it goes without saying that the C standard allows such a choice even today, and an implementation could choose to document that memcpy is well-behaved in that implementation. Undefined behavior doesn't mean that what will happen must be bad, only that what does happen is completely up to the implementation. Unfortunately more and more compiler writers are taking the attitude that any tiny bit of freedom in the direction of undefined behavior should be taken advantage of in pursuit of even the most trivial possible gain in performance, at the cost of ripping the code to shreds and making C less reliable than it could be (and should be). In some sense I am agreeing that the problem here is caused by the C standard, not by it changing in different versions but by it giving too much freedom to implementors for so-called "undefined behavior". Sadly the standardization process seems to have been taken over by compiler writers, so the best advice I can offer is to join the ISO C committee and start voting out the lunacy. Alternatively I suppose one could start up a competitive effort to gcc and clang, and offer a compiler that doesn't engage in such shenanigans unless told to do so (and told specifically), and then try to get developers to switch to sane C in preference to the ever-increasingly insane C that is most commonly used today.