From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1941 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit: buffer_feed() Date: Fri, 23 Jan 2009 18:06:00 +0100 Message-ID: <20090123170600.GA12078@skarnet.org> References: <4979C0D6.3000409@dbservice.com> <4979DAC5.8090007@dbservice.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1232730406 27383 80.91.229.12 (23 Jan 2009 17:06:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2009 17:06:46 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-2176-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Jan 23 18:07:59 2009 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1LQPUa-00059Y-ST for gcsg-supervision@gmane.org; Fri, 23 Jan 2009 18:06:52 +0100 Original-Received: (qmail 15574 invoked by uid 76); 23 Jan 2009 17:06:00 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 15560 invoked by uid 1000); 23 Jan 2009 17:06:00 -0000 Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <4979DAC5.8090007@dbservice.com> User-Agent: Mutt/1.4i Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1941 Archived-At: > 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