From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1940 Path: news.gmane.org!not-for-mail From: Tomas Carnecky Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit: buffer_feed() Date: Fri, 23 Jan 2009 15:57:09 +0100 Message-ID: <4979DAC5.8090007@dbservice.com> References: <4979C0D6.3000409@dbservice.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1232722774 30095 80.91.229.12 (23 Jan 2009 14:59:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2009 14:59:34 +0000 (UTC) Cc: supervision@list.skarnet.org To: Charlie Brady Original-X-From: supervision-return-2175-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Jan 23 16:00:45 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 1LQNVg-0004Ir-QT for gcsg-supervision@gmane.org; Fri, 23 Jan 2009 15:59:52 +0100 Original-Received: (qmail 27307 invoked by uid 76); 23 Jan 2009 14:59:02 -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 27295 invoked from network); 23 Jan 2009 14:59:02 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090117 Shredder/3.0b2pre In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1940 Archived-At: On 01/23/2009 03:30 PM, Charlie Brady wrote: > > On Fri, 23 Jan 2009, Tomas Carnecky wrote: > >> I'm looking at the buffer_feed() function in runit and I can't make >> sense of it. I'm in the process of replacing all byte_* functions with >> standard memcpy/memcmp etc, > > Why? byte_copy is a poor reimplementation of memcpy, and memcpy is part of any libc runtime (according to the man page, conforming to: SVr4, 4.3BSD, C89, C99, POSIX.1-2001.). Please point my to a single libc that implements malloc, open, write, fork but not memcpy. Also, it makes the executable smaller and faster, the project as a whole faster to compile, the code easier to read etc. But nvm, I found out what I was missing. The code still doesn't make sense to me, but at least the resulting executables works correctly. tom