Return-Path: Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: (qmail 13727 invoked from network); 4 Jan 2011 15:27:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jan 2011 15:27:53 -0000 Received: (qmail 81380 invoked by uid 500); 4 Jan 2011 15:27:53 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 81308 invoked by uid 500); 4 Jan 2011 15:27:53 -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 81300 invoked by uid 99); 4 Jan 2011 15:27:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jan 2011 15:27:53 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.47] (HELO mail-ww0-f47.google.com) (74.125.82.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jan 2011 15:27:44 +0000 Received: by wwb39 with SMTP id 39so17103861wwb.16 for ; Tue, 04 Jan 2011 07:27:23 -0800 (PST) Received: by 10.216.150.164 with SMTP id z36mr22437455wej.52.1294154842795; Tue, 04 Jan 2011 07:27:22 -0800 (PST) Received: from zulu.23.e-reka.si (cpe-85-10-13-230.dynamic.amis.net [85.10.13.230]) by mx.google.com with ESMTPS id c54sm5563423wer.6.2011.01.04.07.27.21 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 07:27:21 -0800 (PST) Message-ID: <4D233C57.6030405@xbc.nu> Date: Tue, 04 Jan 2011 16:27:19 +0100 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dev@subversion.apache.org Subject: Re: svn commit: r1053996 [1/2] - in /subversion/trunk/subversion: include/ include/private/ libsvn_client/ libsvn_diff/ libsvn_fs_base/ libsvn_fs_base/bdb/ libsvn_fs_fs/ libsvn_ra_neon/ libsvn_ra_serf/ libsvn_ra_svn/ libsvn_subr/ libsvn_wc/ mod_authz_svn/ ... References: <20101230201356.2824E23888BD@eris.apache.org> <878vz07l1m.fsf@stat.home.lan> In-Reply-To: <878vz07l1m.fsf@stat.home.lan> X-Enigmail-Version: 1.1.1 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRF IhsbCy0qZjoVOVRoeFxSAIKBzXQiAKaibYiewnk7nn9z0qCTgL3i87Ep6Kx/+tHBsrE+zgAAAjZJ REFUOMvF0jFoE1EYB/CzjWlqIzaTjqVIBifRRWyG0t5iUqlLyFpCeXBgKg5yq6A4degUDJjoUDpc 1Qt4Ux94B11SOLB0KGS4discpbkORTCn9/m9d3fvLhXnvuHu3f+Xx/veyyfZfLSdZHzgicSfeyw4 JISwdz8FT6M8lM8Ceg385Dlhs+cC9sQCDn0B78QCogzwN+sxfHGOIXBbRGkNAM4cZymGtgNsDPgz cByxon3EEm1TLmvAlghoHOO3CZSa+IQ/vF6JV8tgKOMow78gRgL2/+EIvATOUtB3SSdMg4GXgrbn uk0uLiGdoCHKbX4E+t1FUTqn1AtIdPJebssDQ64YANSQyyaQNyUOFs0ijMsMFnOPTahPLXKYowtY 08MfCP7vR7hRnc5zmPK7CDYYbHcbC7tHuyFA94U/1LYZaJpu/sxACHMwvwZljTLY0TbNk4x+zuEt yC3MfCM6uSIvfwur0itFL4FA2Yal8BzLfnYV4EIGwEPAk7o5zIcnvzHMEjwJrrhAKK7on6IrsfRJ 7A53BhaK+CL7fj6+q/sPeOvcDTtoZTxpUYsFeIknrOXep3p3l7Ua+8sZ5FPQKyKwWi+DfROTU7ny C1/9UhpeY7K287WJCzbsNPQm2S6Yk4PSCNhWM2r3nD0K9liYb6yPgCRJhSzPrxUK0yUBVk1VX0lj s7MzGZyp0wImMK/e8rHbz2soL+O+2r1dxfGsAmBcx0lNjS/RUhlUC7gRn1wGMdQ7Vw1/AReW/RN3 xFWdAAAAAElFTkSuQmCC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 04.01.2011 16:20, Philip Martin wrote: > danielsh@apache.org writes: > >> Author: danielsh >> Date: Thu Dec 30 20:13:50 2010 >> New Revision: 1053996 >> >> URL: http://svn.apache.org/viewvc?rev=1053996&view=rev >> Log: >> Once and for all, name all our anonymous struct/enum typedefs. >> >> Follows up on r1040058, and with thanks to Danny Trebbien. >> >> * everywhere: >> Change 'typedef struct {} foo_t;' to 'typedef struct foo_t {} foo_t;'. > If there is a consensus that this is a good thing to do then we should > add it to our coding guidelines I frankly see no reason at all to do this "everywhere", it's just unnecessary code churn. The struct tags are only useful if the structure references itself (via pointers), and our practice for such cases was to declare the typedef first, and the struct itself below it, and use the typedef name in the struct definition. So unless someone can explain the reasoning why all these anonymous structs and enums etc. should have names -- on technical grounds, not some stylistic hand-waving -- then please revert. -- Brane