Date: Sat, 01 Feb 2003 16:54:07 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Juli Mallett <jmallett@FreeBSD.ORG> Cc: Mark Murray <mark@grondar.org>, Julian Elischer <julian@elischer.org>, current@FreeBSD.ORG Subject: Re: Style fixups for proc.h Message-ID: <200302020054.TAA21506@agamemnon.cnchost.com> In-Reply-To: Your message of "Sat, 01 Feb 2003 16:14:08 PST." <20030201161408.B64200@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I can't see what actual error is avoided by this warning.
s/actual/potential/
>
> If a named prototype clashes with something in global scope,
> isn't it still a shadowing issue? They should probably never
> be *in* scope.
Nothing is being shadowed. Paramater names in a function
prototype (as opposed to a function definition) are simply
not relevant to the compiler (their distinctness, type and
positions are but not the actual names). No potential bug is
being hidden by saying, for example,
int x;
int foo(int x);
It is perfectly fine to later define foo as
int foo(int y)
{
return x + y;
}
The compiler should simply discard any parameter names in a
prototype once the prototype is digested and C programmers
need to know that. Now if parameter y shadows a global y one
may want to be warned about it.
Garrett gives an example:
> Say you have an object and a function declared in global scope:
>
> int foo;
> /* many lines of declarations */
> /* perhaps this is even in a different file */
> void bar(quux_t foo);
>
> At some point, somebody changes the spelling of `foo' and adds a
> preprocessor macro for compatibility:
>
> union baz {
> int foo;
> struct frotz *gorp;
> } foobaz;
> #define foo foobaz.foo
>
> What happens to the declaration of that function? Well,
>
> void bar(quux_t foobaz.foo);
>
> is a syntax error.
This sort of problem can occur when you have any two objects named the
same. Consider:
struct dumb { int foo; };
After the above redefinition this defn won't compile (even
after his amendation:-).
Not naming parameters is one solution but with some loss of
perspicuity. Consider:
int* make_matrix(int, int);
versus
int* make_matrix(int rows, int columns);
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302020054.TAA21506>