Date: Sat, 2 Feb 2002 05:21:58 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@village.org> Cc: <estabur@hotmail.com>, <arch@FreeBSD.ORG> Subject: Re: __P macro question Message-ID: <20020202045410.U4512-100000@gamplex.bde.org> In-Reply-To: <20020201.095230.12730857.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Feb 2002, M. Warner Losh wrote:
> In message: <20020202012011.U3304-100000@gamplex.bde.org>
> Bruce Evans <bde@zeta.org.au> 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) ^static<tab>void foo(char);
> 3) ^static void<tab>foo(char);
> 4) ^static<tab>void<tab>foo(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:
^void<tab>foo __P((int));
I would just substitute away '<whitespace>__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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020202045410.U4512-100000>