Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964937AbVITIxs (ORCPT ); Tue, 20 Sep 2005 04:53:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964939AbVITIxs (ORCPT ); Tue, 20 Sep 2005 04:53:48 -0400 Received: from nproxy.gmail.com ([64.233.182.206]:4115 "EHLO nproxy.gmail.com") by vger.kernel.org with ESMTP id S964937AbVITIxq convert rfc822-to-8bit (ORCPT ); Tue, 20 Sep 2005 04:53:46 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ItinZq0vmuih/ars3au+gMLY7pEzgHaOEtTACwk5NI2MVNJFGPKdTAa/UYT0yJKqTkppMwkW3uDOZIsLe5tmPouf6CATMj8IEXMX9k8tdRaYlnM7un+vuL5BUrXXjojAv1LVQKHAKJEwSNh+jqBB+lIbRdoNTpfa9Jbeig3+fB4= Message-ID: <84144f020509200153f0becf2@mail.gmail.com> Date: Tue, 20 Sep 2005 11:53:42 +0300 From: Pekka Enberg Reply-To: Pekka Enberg To: Robert Love Subject: Re: p = kmalloc(sizeof(*p), ) Cc: Russell King , Linux Kernel List , Linus Torvalds , Al Viro In-Reply-To: <1127061146.6939.6.camel@phantasy> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <20050918100627.GA16007@flint.arm.linux.org.uk> <1127061146.6939.6.camel@phantasy> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1071 Lines: 21 On 9/18/05, Robert Love wrote: > 5. Contrary to the above statement, such coding style does not help, > but in fact hurts, readability. How on Earth is sizeof(*p) more > readable and information-rich than sizeof(struct foo)? It looks > like the remains of a 5,000 year old wolverine's spleen and > conveys no information about the type of the object that is being > created. Yes it does. The semantics are clearly "I want enough memory to hold the type this pointer points to." While sizeof(struct foo) might seem more readable, it is in fact not as you have no way of knowing whether the allocation is correct or not by looking at the line. So for spotting allocation errors with grep, the shorter form is better (and arguably less error-prone). Pekka - 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/