linux-kernel - Re: checkpatch, a patch checking script.

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]

Message-ID: <Pine.LNX.4.61.0704281240390.506@yvahk01.tjqt.qr>
Date:	Sat, 28 Apr 2007 12:53:51 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Roland Dreier <rdreier@...co.com>, Dave Jones <davej@...hat.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: checkpatch, a patch checking script.

On Apr 28 2007 01:16, Andrew Morton wrote:
>On Sat, 28 Apr 2007 10:01:00 +0200 (MEST) Jan Engelhardt wrote:
>
>> And since when is uint32_t wrong? What makes u32 or __u32 better?
>
>There's not much to be said in favour of u32, really.  Except it's
>shorter and I can never remember where the underscore goes in uint_32t.

The underscore always goes before the final t (short for type I assume).
The typedefs in the kernel do the same... kmem_cache_t (now replaced,
though) as an example.

>If kernel used u_int32_t globally then the world would probably be a
>better place.  But using just the one name has its advantages from a
>consistency POV.

#undef u32
#undef u_int32_t

>box:/usr/src/linux-2.6.21> grep -r '[   \(]u32' . | wc -l
>39599
>box:/usr/src/linux-2.6.21> grep -r '[   \(]uint32_t' . | wc -l 
>5132

Once again, \b comes to the rescue! :)
[And it also works with u32 at SOL and EOLs, and -o counts the number of
occurrences, not the number of lines]

grep -or '\b__uX\b' . | wc -l

.----..-------.------.---------.----------..------.------.--------.
|    ||    uX | __uX | uintX_t | u_intX_t ||   sX | __sX | intX_t |
>====**=======*======*=========*==========**======*======*========<
|  8 || 28004 | 6159 |    3883 |      422 ||  416 |   65 |     75 |
| 16 || 13734 | 3557 |    2613 |      426 ||  393 |  128 |     19 |
| 32 || 42971 | 6656 |    5416 |      879 || 1442 |  363 |    428 |
| 64 || 11219 | 1613 |     811 |       59 || 1061 |   81 |    111 |
`----^^-------^------^---------^----------^^------^------^--------'

The tendency towards __uX and uX is probably because these have been
existent since decades, even before stdint.h and uintX_t got introduced.
Which btw, is another point. Userspace programs that need to include
files from /usr/include/linux sometimes have a hard time compiling
because they want u8, which is defined (or not!) somewhere in
/usr/include/asm. Maybe it is not a problem anymore today, but I had
had it often enough to call it a problem. This is where uintX_t could come
a little more handy, because userspace has a higher chance of already
knowing it through stdint.h or some compiler foo.

Jan
-- 
-
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/