[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46657988.6060901@gmail.com>
Date: Tue, 05 Jun 2007 16:56:08 +0200
From: Rene Herman <rene.herman@...il.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: "John Anthony Kazos Jr." <jakj@...-k-j.com>,
Christoph Lameter <clameter@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...helsinki.fi>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)
On 06/05/2007 04:40 PM, Jeremy Fitzhardinge wrote:
> Rene Herman wrote:
>> No, what we have is a sizeof(pointer) sized pointer pointing to an
>> object of size zero. ZERO_SIZE_PTR is butt-ugly. With a really ugly butt.
>
> It doesn't matter. It will never, ever, be used by anything except the
> kmalloc internals. No client code should ever use the constant for
> anything.
Yes, I'm aware of this (I should snip less) but I still feel it's not a good
name. When I read say "a 64-bit pointer" I immediately take that to mean a
pointer of size 64-bit, not a pointer to 64-bits and only it not making any
sense would stop me from interpreting "ZERO_SIZE_PTR" similarly.
Yes, it's internal but given that this is open-source which, optimistically, is
read many more times than it's written one should still strive for code that
reads nice as far as I'm concerned. It's obviously also not hugely important but
it's just that ZERO_SIZE_PTR makes my neck hair stand up.
Rene.
-
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/
Powered by blists - more mailing lists