Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DDEEE189DF for ; Tue, 11 Aug 2015 22:31:38 +0000 (UTC) Received: (qmail 73123 invoked by uid 500); 11 Aug 2015 22:31:29 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 73072 invoked by uid 500); 11 Aug 2015 22:31:29 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 73057 invoked by uid 99); 11 Aug 2015 22:31:29 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2015 22:31:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 7C61DDC51A for ; Tue, 11 Aug 2015 22:31:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=daniel.shahaf.name header.b=qw7//Qcr; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=BK9uGum6 Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id k4_v8Qhcm3wa for ; Tue, 11 Aug 2015 22:31:20 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 72348428CC for ; Tue, 11 Aug 2015 22:31:20 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 46BC1233CD; Tue, 11 Aug 2015 18:31:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 11 Aug 2015 18:31:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=B0ULhugEMOuJFD3y JoCET2c0D4U=; b=qw7//Qcrqy6nwTQ4K+zb/M/MqCiRSSVfxjYGbsTtwKjUd5a1 qmsqG92N3FDfHEJ+02m1hGXL/nUXfba1NJSTqO0vV4ln8VLkf5o34w5NSpCEvqI+ uGU3efWiv6zBXup0UZeXnSXmqzWKXZZlaXkBgIUUIcfZMWvqrgLAfy5ITRw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=B0ULhugEMOuJFD3 yJoCET2c0D4U=; b=BK9uGum6iCD0StHafSinW5wG80PCLfwrNq8kS5n6SMZMU3U QbY3ZnGj4jC0zu9onxA89W/0XaIYDXhVJ6sel9izklbVXmNqVxMyhSuz5vouKrkT MGPj1fFVi9FmO2aI5SYk9CCVB0NL9J0VNEgCDJL8dyWLZUzxn+Gw78S63Q+U= X-Sasl-enc: +HtINdPrqLxvRGm1VU2P3LGJSrrLqJrReHTh4NuY7kZL 1439332273 Received: from tarsus.local2 (bzq-79-181-180-191.red.bezeqint.net [79.181.180.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 9AE79C00014 for ; Tue, 11 Aug 2015 18:31:13 -0400 (EDT) Date: Tue, 11 Aug 2015 22:31:11 +0000 From: Daniel Shahaf To: dev@subversion.apache.org Subject: Re: Review of sizeof usage Message-ID: <20150811223111.GH1859@tarsus.local2> References: <87pp2tvpfc.fsf@wandisco.com> <55CA5344.8090005@wandisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55CA5344.8090005@wandisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Branko Čibej wrote on Tue, Aug 11, 2015 at 21:55:48 +0200: > On 11.08.2015 17:02, Philip Martin wrote: > > Stefan Fuhrmann writes: > > > >> way we use sizeof. In my opinion, we should take the > >> size of the created or processed variable instead of its > >> type, i.e. > >> > >> abc_t *v = apr_pcalloc(pool, sizeof(*v)); > >> apr_hash_set(hash, key, sizeof(*key), y); > >> z = apr_hash_get(hash, key, sizeof(*key)); > >> > >> rather than > >> > >> abc_t *v = apr_pcalloc(pool, sizeof(abc_t)); > >> apr_hash_set(hash, key, sizeof(key_t), y); > >> z = apr_hash_get(hash, key, sizeof(key_t)); Both of these variants are redundant. We could encapsulate the redundancy in a macro: #define SVN__CALLOC(obj, pool) do { (obj) = apr_pcalloc((pool), sizeof(*(obj))); } while (0) { abc_t *v; SVN__CALLOC(v, pool); } > > We have had problems with both styles in the past, so neither is immune > > to bugs. I prefer the explicit type as it is easier to grep. > > The explicit type form is more accident-prone than the variable form > because any change requires two modifications in the same statement > instead of one. Why doesn't the compiler or buildbot catch accidents?