On 02/09/2012 10:53 AM, Laine Stump wrote: >>> memmove(ret->server, ret->server+1, last-1) >> I know about memmove(), it's just that in this case I really didn't like >> that it copes the string somewhere else and than again back (in case of >> overlapping) but no problem to change this :-) > > I would be surprised if gcc's memmove was that braindead. Especially > when moving memory to a lower address, they can still use the same rep > movs (or whatever) and it goes in the correct direction already - don't > even have to reverse it. The manpage doesn't say that the bytes *are* > copied into a temporary array and back, it just says "copying takes > place *as if* the bytes are first copied into a temporary array". Agreed. Any libc worth their salt implements memmove by first checking for overlap, and if there is overlap, then choosing to start the move from the direction that won't be self-destructive, without using any secondary bank; and furthermore libc will optimize things into word-size chunks for faster than byte-wise motion. Furthermore, while some hardware is tuned only for forward copies, my recollection is that x86 has a rich enough instruction set to iterate the copy in either direction with equal speed. You're almost always better off calling into libc than doing a hand-rolled implementation, except in one case: POSIX currently says that memmove, memcpy, strstr, and other functions in <string.h> are not async-signal-safe. If you are paranoid, you cannot call these functions, but can instead call a hand-rolled implementation, from inside a signal handler or between fork and exec. Or, if you are like me, you will assume that this is a bug in POSIX, and that it was oversight in the standard for omitting functions that are obviously implementable in a signal-safe manner. (Actually, I think there may be a real reason why they are not listed as signal-safe - if there is hardware like x86 that has shortcut instructions like rep movs, but where the shortcut cannot be resumed if it gets interrupted midstream; but I've never seen a web site stating that such an awful hardware design exists in practice). -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list