On Jan 28, 3:43pm, vlsidesign <ford...@gmail.com> wrote:
> I am a newbie to C, and was hoping to get a little bit better handle
> on this until I get deeper into pointers, etc. I kind of understand it
> some, but still unfamiliar because I haven't got to pointers and using
> them yet. Here is my program:
>
> #include <stdio.h>
> int main()
> {
> char yourname[10];
> int yourworth;
>
> printf("what's your name? ");
> scanf(" %s", yourname);
> printf("how many millions of dollars are you worth? ");
> scanf(" %d", &yourworth);
> printf("\n %s is worth %d \n", yourname, yourworth);
> return 0;
>
> }
>
> I think that the scanf needs the second argument to be a pointer? I
> believe that the value of a pointer is an memory address (which the &
> ampersand address operator) retrieves? So when I put an ampersand in
> front of the variable name "yourworth" that it returns the address,
> which then the scanf then puts the value scanned into that memory
> location? In the case of a string, which is just an array of
> characters, like "yourname" above, it is really a pointer anyway, and
> it's value is already an address, so the ampersand is not needed
> anyway??

From the C-FAQ:

6.3: So what is meant by the "equivalence of pointers and arrays"
in
C?

A: Much of the confusion surrounding arrays and pointers in C can
be traced to a misunderstanding of this statement. Saying
that
arrays and pointers are "equivalent" means neither that they
are
identical nor even interchangeable. What it means is that
array
and pointer arithmetic is defined such that a pointer can be
conveniently used to access an array or to simulate an array.

Specifically, the cornerstone of the equivalence is this key
definition:

An lvalue of type array-of-T which appears in an
expression decays (with three exceptions) into a
pointer to its first element; the type of the
resultant pointer is pointer-to-T.

That is, whenever an array appears in an expression,
the compiler implicitly generates a pointer to the array's
first element, just as if the programmer had written &a[0].
(The exceptions are when the array is the operand of a sizeof
or
& operator, or is a string literal initializer for a character
array.)

As a consequence of this definition, the compiler doesn't
apply
the array subscripting operator [] that differently to arrays
and pointers, after all. In an expression of the form a[i],
the
array decays into a pointer, following the rule above, and is
then subscripted just as would be a pointer variable in the
expression p[i] (although the eventual memory accesses will be
different, as explained in question 6.2). If you were to
assign
the array's address to the pointer:

p = a;

then p[3] and a[3] would access the same element.

See also questions 6.8 and 6.14.

References: K&R1 Sec. 5.3 pp. 93-6; K&R2 Sec. 5.3 p. 99; ISO
Sec. 6.2.2.1, Sec. 6.3.2.1, Sec. 6.3.6; H&S Sec. 5.4.1 p. 124.

6.4: Then why are array and pointer declarations interchangeable as
function formal parameters?

A: It's supposed to be a convenience.

Since arrays decay immediately into pointers, an array is
never
actually passed to a function. Allowing pointer parameters to
be declared as arrays is a simply a way of making it look as
though an array was being passed, perhaps because the
parameter
will be used within the function as if it were an array.
Specifically, any parameter declarations which "look like"
arrays, e.g.

void f(char a[])
{ ... }

are treated by the compiler as if they were pointers, since
that
is what the function will receive if an array is passed:

void f(char *a)
{ ... }

This conversion holds only within function formal parameter
declarations, nowhere else. If the conversion bothers you,
avoid it; many programmers have concluded that the confusion
it
causes outweighs the small advantage of having the declaration
"look like" the call or the uses within the function.

See also question 6.21.

References: K&R1 Sec. 5.3 p. 95, Sec. A10.1 p. 205; K&R2
Sec. 5.3 p. 100, Sec. A8.6.3 p. 218, Sec. A10.1 p. 226; ISO
Sec. 6.5.4.3, Sec. 6.7.1, Sec. 6.9.6; H&S Sec. 9.3 p. 271;
CT&P
Sec. 3.3 pp. 33-4.