Re: Computer architects leaving Intel...

Michael S <already5chosen@yahoo.com> writes:

On Mon, 02 Sep 2024 06:59:32 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:
>

On Mon, 2 Sep 2024 5:55:34 +0000, Thomas Koenig wrote:
>

George Neuner <gneuner2@comcast.net> 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.