[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <51189954-4301-4C83-91F2-26B376D0DDD7@mac.com>
Date: Sat, 25 Aug 2007 21:52:51 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: Jesper Juhl <jesper.juhl@...il.com>
Cc: "Robert P. J. Day" <rpjday@...dspring.com>,
Denys Vlasenko <vda.linux@...glemail.com>,
linux-mtd@...ts.infradead.org,
David Woodhouse <dwmw2@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/30] mtd: Don't cast kmalloc() return value in drivers/mtd/maps/pmcmsp-flash.c
On Aug 25, 2007, at 20:36:32, Jesper Juhl wrote:
> On 26/08/07, Robert P. J. Day <rpjday@...dspring.com> wrote:
>> technically, nothing. but if you're not going to use kcalloc()
>> when you're explicitly allocating an array of identical objects
>> (that you want zero-filled, as a bonus), then what's the point of
>> ever having defined a kcalloc() routine in the first place?
>>
> I wonder a bit about that myself...
>
> I have found some other issues in that function that I want to fix,
> so I'll be respinning the patch as a patch series instead - and why
> not; I'll just go with kcalloc() and see what the maintainers have
> to say, it's not like I personally care much one way or the other.
I think the original reasoning behind kcalloc() was that it did some
extra input checking, so that if the product of the two numbers
overflowed, it would fail with NULL instead of allocating
insufficient space. In the kernel it doesn't matter in practice
since you MUST have additional checking on the size of allocated
memory anyways, not even considering the fact that >PAGE_SIZE
allocations are probably going to fail with decent frequency regardless.
Cheers,
Kyle Moffett
-
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