linux-kernel - Re: [PATCH 2/3] lib: vsprintf: optimised put

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 06 Aug 2010 09:08:11 +0200
From:	Michal Nazarewicz <mina86@...a86.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	linux-kernel@...r.kernel.org, m.nazarewicz@...sung.com,
	"Douglas W. Jones" <jones@...uiowa.edu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/3] lib: vsprintf: optimised put_dec() for 32-bit machines

Denys Vlasenko <vda.linux@...glemail.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 will
decide whether to accept this patch or not.  (Also we win a few bytes on
put_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't
see it being larger in any foreseeable feature.  Wouldn't it be enough
to 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--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/