From owner-freebsd-arch Fri Feb 1 10:22:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 94C8637B400 for ; Fri, 1 Feb 2002 10:22:42 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA25879; Sat, 2 Feb 2002 05:19:52 +1100 Date: Sat, 2 Feb 2002 05:21:58 +1100 (EST) From: Bruce Evans X-X-Sender: To: "M. Warner Losh" Cc: , Subject: Re: __P macro question In-Reply-To: <20020201.095230.12730857.imp@village.org> Message-ID: <20020202045410.U4512-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Feb 2002, M. Warner Losh wrote: > In message: <20020202012011.U3304-100000@gamplex.bde.org> > Bruce Evans writes: > : > Are you perhaps objecting to the type of the last parameter > : > ("int format" vs "char format")? Please see Ansi Classic, chapter > : > "3.5.4.3 Function declarators (including prototypes)", in particular > : > page 69 lines 19-22. In C99, 6.7.5.3 paragraph #11 seems to apply > : > similarly. > : > : Right. I don't trust anyone who is not familiar with this point to > : globally remove __P. > > So do I qualify? We all know that the original poster of the comment > didn't understand this subtlty. :-) Better than the original poster :-). The original poster did md5 regression checks which would help. I think the global changes should just stay away from areas that can't be checked automatically. > : People removing __P should also be familiar with the gcc conterpoint: > : > : void foo(char); /* Wrong; should be "void foo(int);". */ > : void foo(c) char c; {} > : > : gives undefined behaviour in Standard C, but gcc defines its behaviour > : to be do-what-naive-programmer-expects. This is only safe provided the > : wrong prototype for foo() is always in scope before foo() is called; > : otherwise foo() is sometimes passed an int and sometimes a char, but > : foo() expects to be passed either an int or a char depending on whether > : the wrong prototype is in scope for the function body. > > Alternatively: > void foo(char); > void foo(char c) { } > would be right. :-) I've already found three places where this didn't > hold. It's as right as the gcc rewriting of the function definition, but is a semantic change and it should be checked carefully. gcc on i386's seems to have stopped pessimizing it; gcc on i386's doesn't optimize it either (for compatibility with binary interfaces suitable for K&R compilers :-(), so there is some change of checking the change automatically. > So what is the right style: > > 1) ^static void foo(char); > 2) ^staticvoid foo(char); > 3) ^static voidfoo(char); > 4) ^staticvoidfoo(char); > > Most of the tree I've looked at so far uses #1. I'm a little > reluctant to change that part of things on this pass. Most of it doesn't use static yet, and the KNF parts use: ^voidfoo __P((int)); I would just substitute away '__P((' and change '))' at the end of the same lines as __P(( to to ')', and not touch any other whitespace. Lines that don't match the simple regexp for this probably have style problems, e.g., ones involving line breaks for long lines. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message