Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: memcpy
Message-ID: <3811@goanna.cs.rmit.oz.au>
Date: 24 Sep 90 11:32:53 GMT
References: <1990Sep19.021418.11574@maths.tcd.ie> <187@thor.UUCP> <STEPHEN.90Sep22181237@estragon.uchicago.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 44

In article <STEPHEN.90Sep22181237@estragon.uchicago.edu>, stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
> As to why this code works at all, it turns out that on most machines
> the appropriate stupid implementation IS the fastest; in fact on most
> of the CISC micros there's an instruction that does exactly that, and
> does it very fast indeed (being an instruction, not a loop).

But "some of the world _IS_ a VAX".  The VAX instructions for this
(MOVC3, MOVC5) do it the memmove() way.  On the NS32x32, there's a MOVS
instruction, but you have to set up the registers for it, and it has a
"backwards" option, so the entire overhead for a naive memmove() compared
with a naive memcpy() would be one comparison and one conditional
branch.  By the time you add the code to check for an opportunity to
move 16-bit (MOVSW) or 32-bit (MOVSD) chunks instead of 8-bit (MOVSB)
ones, the overhead of memmove() has disappeared in the noise.

> Furthermore, since it doesn't contain any transfers of control if it
> arrives as an instruction, many compilers will inline it.

Transfers of control needn't stop a compiler inlining it _anyway_.

> So what the situation amounts to is an assumption on the part of the
> programmer that having been given the freedom to implement memcpy()
> however you like in this case, that any "sane" implementor would do it
> the "easy" way

You are making quite unwarranted assumptions about what is "easy".
"however you like" means HOWEVER the implementor likes.
To quote the Goon Show:
	Man from the Geographical Society:
		"There are idiots in the world, you know."
	Neddie Seagoon:
		"Have you met them?"
	Man from the Geographical Society:
		"Met them?  I listen to you every week!"

There are a lot of tiny little dark spots in ANSI C where anyone
designing a language would have spelled out what was to be done.
These little dark spots are almost always there because there are
existing not-quite-hopelessly-broken implementations that did things
different ways.  Think of the dark spots as the warning "rattle" of
these implementations poised to bite you.

-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.