Article View: comp.std.c
Article #1739Re: memcpy
From: Doug Gwyn
Date: Fri, 21 Sep 1990 22:01
Date: Fri, 21 Sep 1990 22:01
42 lines
2732 bytes
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!gwynReferences:
<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