Re: [PATCH] Fixed URI parsing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]