Path: 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> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 42 In article 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().