linux-kernel - Re: [PATCH v2 1/2] lib/vsprintf.c: Simplify uuid

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:	5 Jun 2016 15:57:41 -0400
From:	"George Spelvin" <linux@...encehorizons.net>
To:	andriy.shevchenko@...ux.intel.com, linux@...encehorizons.net
Cc:	bjorn@...k.no, linux-kernel@...r.kernel.org,
	matt@...eblueprint.co.uk, rv@...musvillemoes.dk
Subject: Re: [PATCH v2 1/2] lib/vsprintf.c: Simplify uuid_string()

r
>From andriy.shevchenko@...ux.intel.com Sun Jun 05 14:21:40 2016
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,421,1459839600"; 
   d="scan'208";a="969274163"
Subject: Re: [PATCH v2 1/2] lib/vsprintf.c: Simplify uuid_string()
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: George Spelvin <linux@...encehorizons.net>
Cc: bjorn@...k.no, linux-kernel@...r.kernel.org, matt@...eblueprint.co.uk, 
	rv@...musvillemoes.dk
Date: Sun, 05 Jun 2016 17:22:56 +0300
In-Reply-To: <20160604051411.3635.qmail@...sciencehorizons.net>
References: <20160604051411.3635.qmail@...sciencehorizons.net>
Organization: Intel Finland Oy
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.2-2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

Andy Shevchenko wrote:
> On Sat, 2016-06-04 at 01:14 -0400, George Spelvin wrote:
>> -		if (uc)
>> -			p = hex_byte_pack_upper(p, addr[index[i]]);
>> -		else
>> -			p = hex_byte_pack(p, addr[index[i]]);
>> +		u8 byte = addr[index[i]];
>> +
>> +		*p++ = hex[byte >> 4];
>> +		*p++ = hex[byte & 0x0f];

> And what prevents you to assign hex_byte_pack()/hex_byte_pack_upper()
> and do one call here?

Because they're inline functions, so there's no compiled copy to
take the address of.

Since they're delcared "static", if you take their addresses anyway,
gcc will helpfully compile private versions for the use of this source
file, which will be bigger and slower than the simple inline expansion
I used here.

It's not even any *simpler*.  Remembering what "hex_byte_pack()" means
is as much mental effort as interpreting those two very simple lines.

There's no strong reason to *avoid* using the hex_asc[] arrays directly.
It's done in several other places in the kernel, including earlier in
lib/vsprintf.c (search for "hex_asc_upper" in number()).

If they were intended to be "off limits", they would have been given
_-prefixed names.