global scope on paramaters

[Troll_King]

Why do the implementors declare the function parameters with global
scope. Why aren't the parameter declarations just comments that help
readability. Doesn't this make the parameters visible to rest of the
file.

FTS *
fts_open(argv, options, compar)
char * const *argv;
register int options;
int (*compar) __P((const FTSENT **, const FTSENT **));
{
register FTS *sp;
register FTSENT *p, *root;
register int nitems;
FTSENT *parent, *tmp;
int len;

/* Options check. */
if (options & ~FTS_OPTIONMASK) {
__set_errno (EINVAL);
return (NULL);
}
.....

/*-
* Copyright (c) 1990, 1993, 1994
* The Regents of the University of California. All rights
reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above
copyright
* notice, this list of conditions and the following disclaimer in
the
* documentation and/or other materials provided with the
distribution.
* 4. Neither the name of the University nor the names of its
contributors
* may be used to endorse or promote products derived from this
software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS''
AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF
* SUCH DAMAGE.
*/
}

[Mark A. Odell]

tr*******@shaw.ca (Troll_King) wrote in
news:39**************************@posting.google.c om:

Why do the implementors declare the function parameters with global
scope. Why aren't the parameter declarations just comments that help
readability. Doesn't this make the parameters visible to rest of the
file.

FTS *
fts_open(argv, options, compar)
char * const *argv;
register int options;
int (*compar) __P((const FTSENT **, const FTSENT **));
{

These parameters aren't global in scope, they're declared in the old
pre-ANSI way. Pretend they are just regular parameters - since they are.

--
- Mark ->
--

[Chris Torek]

In article <news:39**************************@posting.google. com>
Troll_King <tr*******@shaw.ca> writes:

Why do the implementors declare the function parameters with global
scope.
This is the old K&R-1 syntax. The parameters are still local to
the function:
FTS *
fts_open(argv, options, compar)
char * const *argv;
register int options;
int (*compar) __P((const FTSENT **, const FTSENT **));
{ [initial body snipped; and] * Copyright (c) 1990, 1993, 1994
* The Regents of the University of California.

This code has its origins in a clone of the System V "ftw" routine.
This was started before the 1989 C standard existed. Note the use
of the "__P" macro (which lives in the implementor's name space,
but then, we were the implementors!). The code still had to pass
through the old, non-ANSI compilers we were using at UCB at the
time, so using the newfangled prototype syntax was not permitted.
(K&R-1-only compilers were still being used as late as Jan 1994 at
least, about the time I joined BSDI. We were using gcc -- version
1.something -- on the SPARC by then, but I am not sure if anyone
ever wrote a back end for gcc for the Tahoe. Later in the 1990s
I started agitating to convert everything to prototype syntax, but
by then the original code was widespread.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.