Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!accelerator.eng.ohio-state.edu!kaa.eng.ohio-state.edu!rob
From: rob@kaa.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.lang.c
Subject: Re: Double inderection question
Keywords: is this messed up or am I?
Message-ID: <431@accelerator.eng.ohio-state.edu>
Date: 3 Aug 88 03:37:25 GMT
References: <2001@tulum.cs.swarthmore.edu>
Sender: news@accelerator.eng.ohio-state.edu
Reply-To: rob@kaa.eng.ohio-state.edu (Rob Carriere)
Organization: Ohio State Univ, College of Engineering
Lines: 32

In article <2001@tulum.cs.swarthmore.edu> pomeranz@cs.swarthmore.edu (Hal Pomeranz) writes:
>
>Consider the following:
>
>char array[10], **ptr;
>
> [ and now ptr cannot be assigned the value &array ]

This is as it is supposed to be.  Consider: the name of array *does*
(as you said) represent a pointer to the start of the array, but, and
this is the crucial fine print, NO STORAGE HAS BEEN ALLOCATED FOR THAT
POINTER!  It is a compiler constant.  One way to look at this is to
say that what you are doing is similar to:

int *foo = &1;

Which is also wrong (thank God!  One language called FORTRAN is quite
enough!).

Now in your second fragment, *you* create a space for this array
pointer to go, and then you *can* refer to it to your hearts content.
Carrying on my metaphor, this is similar to:

int  bar = 1;
int *foo = &bar;

Which will work too.

Summary: there was nothing *wrong* with the rules, they were just a
little ( :-) obscure.  

Rob Carriere