`Denys Vlasenko <vda.linux@googlemail.com> writes:> On Friday 06 August 2010 00:38, Michal Nazarewicz wrote:>> The disadvantage is that the proposed function is 2.5-3.5 bigger.>> Those are not big functions though -- we are talking here about>> proposed function being below 512.> It's a slippery slope. Here's where it ends: glibc> has memcpy() function which is "only" 8k of code or so.> I'm not joking.I'm aware of that.  I assume that someone more clever then me willdecide whether to accept this patch or not.  (Also we win a few bytes onput_dec_full() and put_dec_8bit()). :P>> +#if BITS_PER_LONG == 64>> +> ...  >> +#else> ...>> +/*>> + * Based on code by Douglas W. Jones found at>> + * <http://www.cs.uiowa.edu/~jones/bcd/decimal.html#sixtyfour>.  This>> + * performs no 64-bit division and hence should be faster on 32-bit>> + * machines then the version of the function above.>> + */>> +static noinline_for_stack>> +char *put_dec(char *buf, unsigned long long n)>> +{>> +	uint32_t d3, d2, d1, q;>> +>> +	if (!n) {>> +		*buf++ = '0';>> +		return buf;>> +	}>> +>> +	d1  = (n >> 16) & 0xFFFF;>> +	d2  = (n >> 32) & 0xFFFF;>> +	d3  = (n >> 48) & 0xFFFF;>> Are you assuming that sizeof(long long) == 8, always?Well...  yes.  C requires long long to be at least 64-bit and I don'tsee it being larger in any foreseeable feature.  Wouldn't it be enoughto put a static assert here?-- Best regards,                                         _     _ .o. | Liege of Serenly Enlightened Majesty of      o' \,=./ `o ..o | Computer Science,  Michal "mina86" Nazarewicz   (o o) ooo +--<mina86-tlen.pl>--<jid:mina86-jabber.org>--ooO--(_)--Ooo--`