lkml.org 
[lkml]   [2005]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: p = kmalloc(sizeof(*p), )
On Tue, Sep 20, 2005 at 10:11:28AM -0700, Andrew Morton wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> >
> > Since some of the other major contributors to the kernel appear to
> > also disagree with the statement, I think that the entry in
> > CodingStyle must be removed.
>
> Nobody has put forward a decent reason for doing so. "I want to grep for
> initialisations" is pretty pointless because a) it won't catch everything
> anyway and b) most structures are allocated and initialised at a single
> place and many of those which aren't should probably be converted to do
> that anyway.
>
> The broader point is that you're trying to optimise for the wrong thing.
> We should optimise for those who read code, not for those who write it.
>
> Every time I see such a type-unsafe allocation in a patch I have to go hunt
> down the definition of the lhs. Which is sometimes in a header file, often
> one which hasn't been indexed yet. Is a pita.

Well, as I've said, don't expect folk to change their style just
because something has been decided privately amongst a small select
group of folk (which is exactly what seems to have happened - maybe
not intentionally.)

And don't expect subsystem maintainers to accept the new "style"
guidelines without a fight.

However, if we really are concerned about type-unsafe allocation,
we should be using something like Alan's suggestion, where the
return type from the *alloc function is appropriately typed and
not void *.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-20 19:21    [W:1.731 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site