Matthew Dillon wrote:
> Mark Murray wrote:
> :Then can we just get the proc.h prototypes into a (any) consistent
> :style?
Yes; no brainer, except where Garrett has indicated (e.g. a
function that takes a "fromvp" and "tovp", or other similar arguments).
> Lets ask ourselves what the goal of the named prototypes is... the
> compiler doesn't need them, obviously, so one would presume that the
> goal is human readability.
Technically, the compiler doesn't need prototypes at all; they
are merely a band-aid for the compiler vendors, who did not want
to have to deal with changing object file format. Because of
that, we also have symbol decoration for C++, and we have a C++
compiler that requires explicit declaration of some functions
which should be implicit. If the object file had attribution,
and you wanted to make implied coercion, the linker could emit
glue, as necessary, and be done with it: no prototypes in scope.
If you wanted to disallow implied coercion, it could be a link-time
error. Either way, the same "complaining" could take place, with
no need to abuse the compiler semantics.
Prototypes, in general, are things for compiler vendors, and the
goal of the named arguments in a prototype was, at least at one
point, to help out ANSI C compilers that wanted to requse the
function declaration parsing code, and would barf without some
token there to jam into a symbol table. The "shadowing" warning
that is being complained about by Mark Murray is, as has been
pointed out, a compiler bug: according to the standards, the
symbols are supposed to go out of scope anyway. In fact, it should
ignore tokens to the coma or closing parenthesis, and not be bitching
in the first place.
> So if we care about human readability we should simply name them after
> the argument names used in the procedures proper. If we don't care
> about human readability we should omit the names entirely.
Yes, this makes sense. The grip that Garrett brought up is an
artifact of the compiler being stupid. In fact, the same problem
would occur for the function declaration, and all compilation units
for which there are header files containing prototypes should include
those headers themselves, in order to ensure the prototype was in
scope at the time the function was encountered, to insure against
trivial errors from the prototype not matching the function declaration.
Thus, if the prototype is:
int xxx(int _foo);
Then the function should be:
int xxx(int _foo)
{
}
...since what a
#define foo foobaz.bazu_foo
will do to a prototype declaration, it will surely do to the function
declaration as well, if it is in a header which is in scope at the
time the compiler encounters the actual function declaration.
> An underscore would be detrimental to human readability. It makes the
> prototypes look rather nasty when I look at the fully patched proc.h,
> and also makes them different from the arguments as declared in the
> procedures proper.
It's just ugly, in general, and confusing, when combined with
structure pointer element references. 8-(.
[ ... ]
> And it goes on. Quite a mess we have, actually. We still have __P in
> many places. The newest header file would arguably be acl.h in which
> the author used underscores. I can't say I like the way it reads on the
> screen. Older header files either still have __P, don't have __P and
> the arguments are named (typically without an underscore), or mix with
> some of the arguments named and some not (some wholely not).
So let Mark "correct" them into uniformity; that can be done
without "protecting" everything, which can be done as a seperate
"protection" or "argument name removal" pass.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
