🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #1739

Re: memcpy

#1739
From: Doug Gwyn
Date: Fri, 21 Sep 1990 22:01
42 lines
2732 bytes
In article <BURLEY.90Sep21111221@world.std.com> burley@world.std.com (James C Burley) writes:
>In article <13914@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>   ...  Some memcpy() implementations
>   have attempted to "do the right thing" (meaning: follow the sequential
>   pick-the-entire-block-up-into-a-temporary-register, then-put-the-
>   temporary-register-contents-back-down-at-the-new-location model) for
>   cases of overlaps, while others have not.
>First off, it strikes me (THUNK!  :-) that my expectation of what memmove
>would do is exactly the opposite of what is desired.  If one wants to use
>a memory move to spew a given set of values (in the case discussed here,
>just one) across memory, and indeed the more-than-one case is not covered
>to my knowledge my memset or any other ANSI function, it seems that one does
>not want to use a memory move that is "smart enough" to do an overlapping
>move the "right" way.

It's true that the original application was attempting a "smear" rather
than a "blit" operation, and my previous comments failed to address that.
Previous arguments about memcpy() have focussed on the block-move model
rather than a smearing model, perhaps because very few people think that
the latter is very sensible.  (Note that there are two different smearing
directions, and that applications for smearing are rather rare.)

To smear a single byte, as in the original application, memset() is
recommended.

>Second, I don't think it is necessary for memmove to actually copy into a
>temporary.

No, that was the block-transfer MODEL, not the implementation.

>I think one can do an implementation similar to the following
>...
>if ((source > dest) || (source + n <= dest))
* Warning * Non-portable pointer comparisons in above line.

You can get away with that in a flat virtual address space, but not in
general.  This is essentially the reason for my doubt that a portable
implementation would be possible.  Since then, I have received e-mail
that points out that a portable implementation would be possible by
using pointer equality tests within a loop over object bytes.  This
would, however, be excruciatingly slow, so it still appears that there
is no PRACTICAL portable implementation method for memmove().
Technical Details
Message-ID: <13918@smoke.BRL.MIL>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
References: <1990Sep19.021418.11574@maths.tcd.ie> <13914@smoke.BRL.MIL> <BURLEY.90Sep21111221@world.std.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: memcpy
Message-ID: <13918@smoke.BRL.MIL>
Date: 21 Sep 90 22:01:00 GMT
References: <1990Sep19.021418.11574@maths.tcd.ie> <13914@smoke.BRL.MIL> <BURLEY.90Sep21111221@world.std.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 42