Re: runit: buffer_feed()

[Laurent Bercot <ska-supervision@skarnet.org>]

> byte_copy is a poor reimplementation of memcpy

 Wrong.
 byte_copy works when the source and destination overlap and dst < src.
 byte_copyr works when the source and destination overlap and dst > src.
 memcpy is NOT guaranteed to work when the source and destination overlap.

 If you want an optimized function that works in every case, try memmove.


> Also, it makes the executable smaller and faster, the project as a whole 
> faster to compile, the code easier to read etc.

 Your mileage may vary. I'm used to the byte_copy() interface. :)

 I'm not pretending your remarks are unfounded. The functions in byte.h
and buffer.h are very old DJB code, when he was rewriting the world and
its mother in order to be portable on alien computers pretending to be
half POSIX-compliant.
 I'm not aware of any modern architecture/libc combination where memmove()
doesn't work, so I *think* byte_copy and byte_copyr's naive implementations
can be safely replaced with memmove() (and that's what skalibs does by
default). I could be wrong, though, and be non-portable on a few archs.
 As for buffer.h, I disliked DJB's implementation and rewrote it entirely.
The API, however, is excellent.
 (If I'm not mistaken, buffer_feed() fills the buffer if it's empty (and
doesn't if it's not), and returns the number of bytes in the buffer.)

 What I'm saying is there's risk involved in patching software without
giving it a good deal of thought - especially software including DJB code,
which usually features a number of non-apparent, but important, design
decisions. If you go and wildly replace byte_copy with memcpy, you will
introduce bugs into the code. ;)

-- 
 Laurent