declaring variable and then also in function prototype -- seems weird

[vlsidesign]

Here is my a portion of my program:
#include <stdio.h>
main()
{
int fahr, celsius;
int lower, upper, step;

int fc_conv(int fahr);
... snip ...
}
So I first add the 'int fahr', which is a " ... declaration [that]
announces the properties of the variables; it consists of a type name
and a list of variables..." And then I declare the "... parameter type
and names, and the type of result that the function returns." It seems
almost like I am defining fahr twice. Now I understand that "the called
function is given the values of its arguments in temporary variables
rather than the originals." So this seeming second declaration is
really not, but probably because of this localized copy. But couldn't
it be assumed to be the same type as the previous declaration, or can
you in fact change the local copy to be a float or something? Just
wondering.

All quotes taken from "The C Programming Language by K & R, 2ndEd).

[Richard Heathfield]

vlsidesign said:

Here is my a portion of my program:
#include <stdio.h>
main()
{
int fahr, celsius;
int lower, upper, step;

int fc_conv(int fahr);
... snip ...
}
So I first add the 'int fahr', which is a " ... declaration [that]
announces the properties of the variables; it consists of a type name
and a list of variables..." And then I declare the "... parameter type
and names, and the type of result that the function returns." It seems
almost like I am defining fahr twice.

No.

int fahr; defines an int object, reserving space for it, and associating the
name 'fahr' with it within the scope of the main() function.

int fc_conv(int fahr); declares (but does not define) a function that takes
an integer expression as its only formal parameter and returns an int. You
have chosen to take advantage of the option to add a name for that
parameter within the scope of the function prototype, but you could equally
have written int fc_conv(int); if you wanted.

Now I understand that "the called
function is given the values of its arguments in temporary variables
rather than the originals."

Lies-to-programmers - i.e. a convenient shorthand which doesn't really
reflect what's going on, but which is deemed a "good enough" explanation to
get the student programmer past this point, always trusting that, later on,
they'll get a clearer idea when their knowledge of the language is
broadened.

The "lie" here is "the originals", and it's a lie because there aren't any
originals!

The argument is an *expression*, and that expression is evaluated, and the
value is passed to the function. fc_conv(42) cannot be "given" 42. It must
be given an object with the value 42. 42 itself is not an object. It is an
expression with the value 42, so that value must be stored in an object if
fc_conv() is going to use it.

So this seeming second declaration is
really not, but probably because of this localized copy. But couldn't
it be assumed to be the same type as the previous declaration,

There isn't a previous declaration. The other declaration has nothing
whatsoever to do with this one. You could have written int fc_conv(int
walrus) or int fc_conv(int celsius) or int fc_conv(int lower), or even just
int fc_conv(int) - *without changing the meaning of the program*.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Barry]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:o_******************************@bt.com...

vlsidesign said:

Here is my a portion of my program:
#include <stdio.h>
main()
{
int fahr, celsius;
int lower, upper, step;

int fc_conv(int fahr);
... snip ...
}
So I first add the 'int fahr', which is a " ... declaration [that]
announces the properties of the variables; it consists of a type name
and a list of variables..." And then I declare the "... parameter type
and names, and the type of result that the function returns." It seems
almost like I am defining fahr twice.

No.

int fahr; defines an int object, reserving space for it, and associating

the

name 'fahr' with it within the scope of the main() function.

int fc_conv(int fahr); declares (but does not define) a function that

takes

an integer expression as its only formal parameter and returns an int. You
have chosen to take advantage of the option to add a name for that
parameter within the scope of the function prototype, but you could

equally

have written int fc_conv(int); if you wanted.

Now I understand that "the called
function is given the values of its arguments in temporary variables
rather than the originals."

Lies-to-programmers - i.e. a convenient shorthand which doesn't really
reflect what's going on, but which is deemed a "good enough" explanation

to

get the student programmer past this point, always trusting that, later

on,

they'll get a clearer idea when their knowledge of the language is
broadened.

The "lie" here is "the originals", and it's a lie because there aren't any
originals!

The argument is an *expression*, and that expression is evaluated, and the
value is passed to the function. fc_conv(42) cannot be "given" 42. It must
be given an object with the value 42. 42 itself is not an object. It is an
expression with the value 42, so that value must be stored in an object if
fc_conv() is going to use it.

So this seeming second declaration is
really not, but probably because of this localized copy. But couldn't
it be assumed to be the same type as the previous declaration,

There isn't a previous declaration. The other declaration has nothing
whatsoever to do with this one. You could have written int fc_conv(int
walrus) or int fc_conv(int celsius) or int fc_conv(int lower), or even

just

int fc_conv(int) - *without changing the meaning of the program*.

For shame Mr. Heathfield. You might give windows programmers the
idea that when they read a prototype that says something like

int SomeTypeofCallbackFunc(
int somerediculouslyLongHungarianNotationForanINT)

they don't actually have to name their local variable
somerediculouslyLongHungarianNotationForanINT

or even worse that they don't have to name their callback function
SomeTypeofCallbackFunc

Apparently the latter case was common enough that MS added a
note to their documentation for some functions like:

SomeTypeofCallbackFunc is just a placeholder for your actual
function name.

:-)