From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3288 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [patch] add ether_(aton, ntoa) Date: Sun, 5 May 2013 11:15:47 -0400 Message-ID: <20130505151547.GS20323@brightrain.aerifal.cx> References: <20130415014005.GR20323@brightrain.aerifal.cx> <20130429020757.GV20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367766963 3511 80.91.229.3 (5 May 2013 15:16:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 May 2013 15:16:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3292-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 05 17:16:04 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UZ0fT-00026D-14 for gllmg-musl@plane.gmane.org; Sun, 05 May 2013 17:16:03 +0200 Original-Received: (qmail 23590 invoked by uid 550); 5 May 2013 15:16:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23582 invoked from network); 5 May 2013 15:16:01 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3288 Archived-At: On Sun, May 05, 2013 at 09:11:12AM -0500, Strake wrote: > >> ntoa: same size > >> aton: mine is smaller > > > > This doesn't seem to match my results. I compared against the > > following version of aton and it was half the size of yours: > > > > struct ether_addr *ether_aton_r (const char *x, struct ether_addr *p_a) > > { > > unsigned char *y = p_a->ether_addr_octet; > > char c; > > if (sscanf(x, "%2hhx:%2hhx:%2hhx:%2hhx:%2hhx:%2hhx%c", > > y,y+1,y+2,y+3,y+4,y+5,y+6,&c)!=6) > > return 0; > > return p_a; > > } > > > > Rich > > My method: > > $ cat test.c > #include > > int main (int argc, char *argu[]) { > struct ether_addr *p_a; > p_a = ether_aton (argu[1]); > return (*p_a).ether_addr_octet[0]; > } > > $ cc -I $MUSL/include -L $MUSL/lib -o test test.c && strip test && wc -c > Mine: 6200 > Yours: 15504 I see. These are two different but perfectly valid ways for looking at size: size of the function itself versus size of the function with all its dependencies. My approach to measuring size leads to a smaller libc.so, whereas your approach leads to a smaller statically linked binary when the binary does not otherwise use *scanf for anything. This is an issue that's come up several times before when optimizing for size, and I don't think there's one right answer for all cases. The solution is obvious in cases where the code size without depending on another function is minimal, but when a large function like snprintf or sscanf is involved it's a larger trade-off. My leaning in this case is towards making the ether_* functions as small as possible themselves, without worrying about dependencies. My reasoning is that, on a small system, at most one or two programs will be using these functions anyway, and if it's Busybox (or in the future, Toybox) then scanf is already being pulled in anyway. The main cases where I'd lean the other way are for functions which have usefulness in a large number of programs, some of which may be written in light/minimalistic ways to avoid pulling in stuff like stdio. Anyway, I welcome other comments on the issue; we don't have to make a decision immediately but I'd like to get the ether_* stuff integrated in one form or another soon and have it in the next release. Rich