From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3404 Path: news.gmane.org!not-for-mail From: idunham@lavabit.com Newsgroups: gmane.linux.lib.musl.general Subject: Re: ether_* functions Date: Sat, 8 Jun 2013 08:24:00 -0700 Message-ID: <20130608152400.GA30028@Caracal> References: <20130607162326.GA30843@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 1370705065 22411 80.91.229.3 (8 Jun 2013 15:24:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Jun 2013 15:24:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3408-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 08 17:24:27 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 1UlL0A-0006pP-IE for gllmg-musl@plane.gmane.org; Sat, 08 Jun 2013 17:24:22 +0200 Original-Received: (qmail 28282 invoked by uid 550); 8 Jun 2013 15:24:20 -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 28274 invoked from network); 8 Jun 2013 15:24:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=iaY/VVum1p3mkd6GJJUmRlnkpKF2pL1+iKHJ7in7uK5A6u6eB8PKEsj2a6r17s1uG2+NWTf6BeKKchThX+EnT+GHuUqvRwqVB24i50eVZ5/nj4K2KyT+eej92nHvU8p6n3Q21Bm3SgqnYOTxLezzbqVFSYH+LIuljax+R/cdkWw=; h=Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Content-Disposition: inline In-Reply-To: <20130607162326.GA30843@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3404 Archived-At: On Fri, Jun 07, 2013 at 12:23:26PM -0400, Rich Felker wrote: > Hi all, > > The previous conversation about ether_aton/ntoa trailed off without > really reaching a conclusion. I'd like to get these interfaces > integrated for the next release. Does anyone have opinions on which > version we should use: the think sscanf/snprintf wrappers (which I > proposed), or the versions (by Strake) with all the logic inline that > don't depend on other heavy functions? I was about to say the thin wrappers because I want to avoid bloat in libc.so and in programs that use both ether_* and *printf/sscanf, but how much is the difference in ether_aton_r object size? OK, let's test (Strake's last version vs Rich's scanf version, gcc 4.4 on Debian, musl from within the last couple weeks): /tmp$ /opt/musl/bin/musl-gcc -std=c99 -D_XOPEN_SOURCE=700 -c ether_aton.c /tmp$ /opt/musl/bin/musl-gcc -std=c99 -D_XOPEN_SOURCE=700 -c ether_aton_scanf.c /tmp$ size *.o text data bss dec hex filename 161 0 6 167 a7 ether_aton.o 182 0 0 182 b6 ether_aton_scanf.o With -O3: 328 0 0 328 148 ether_aton.o 142 0 0 142 8e ether_aton_scanf.o With -Os: 101 0 0 101 65 ether_aton.o 113 0 0 113 71 ether_aton_scanf.o Huh? I'm wondering why scanf would be _larger_ with no -O and with -Os. ether_ntoa is using sprintf already. So I'll vote for Strake's version. HTH, Isaac Dunham