Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!im4u!rutgers!sri-unix!sri-spam!mordor!lll-tis!ptsfa!ihnp4!uniq!rjnoe
From: rjnoe@uniq.UUCP (Roger J. Noe)
Newsgroups: comp.lang.c
Subject: Re: static char (*b)[6]; /* an unusual declaration */
Message-ID: <304@uniq.UUCP>
Date: Fri, 12-Jun-87 14:57:09 EDT
Article-I.D.: uniq.304
Posted: Fri Jun 12 14:57:09 1987
Date-Received: Sun, 21-Jun-87 01:40:57 EDT
References: <761@bsu-cs.UUCP>
Organization: Uniq Digital Technologies, Batavia, IL
Lines: 64
Summary: not same as "static char **b", should not be used same way

In article <761@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
> What is the meaning of the following declaration?
>      static char (*b)[6];
> The compiler and lint checker used by the magazine columnist seem to
> treat the declaration of b as equivalent to char ** . . .

But it's obviously NOT equivalent.  You could make a pretty good case
that lint (if not the compiler as well) should complain about the "b = d;"
pointer assignment statement, but that does not excuse the programmer
from understanding the difference between b and d.  (Try passing b to a
function which expects a "char **" argument and see what happens.  You
should see lint complain about a parameter inconsistency and it should
compile and execute correctly.)

As for the example program:
> main()
> {
>      static char (*b)[6];	/* an unusual declaration */
>      static char a[] = "Hello";
>      char *c = a;
>      char **d = &c;
>      b = d;			/* So b == d ... Watch. */
> 
>      printf ("%s\n", *d);	/* prints "Hello" */
>      printf ("%s\n", *b);	/* prints 0 */
> }

change the final printf() call to "printf("%s\n", *(char **)b);" and
everything should work just as you'd expect.  If b is not "char **" and
you dereference it, you're not going to get a "char *", which is what
you'd need to see this do what is desired.

> . . . .  The columnist continues, "...This means
> that *b is a constant and while (b) can be modified, *b never will
> change its original value.  Thus, setting b = d does not mean that 
> *b == *d.  Also, while *b is treated as a constant (unchangeable), the
> value of b can vary."

Incorrect.  The values of b and d are identical, but the programmer has
told the compiler that they do not point to the same types.  The use of
the static (internal) storage class has much less to do with what is
going on here.  All that it does is prevent b from being automatic while
still restricting its scope to main().  The problem is that "*b", as the
program was written, denotes an aggregate array of 6 characters, not a
pointer to them.  The array cannot be passed as a function parameter.

> He goes on to ask if other C compiles do the same thing, and wonders
> if Ritchie had this in mind when he defined the language.

Yes, I suspect most compilers will do the same thing.  I think a C compiler
that worked as the columnist seemed to anticipate would have to be a broken
compiler, or it implements something other than C language.  As far as I
can tell the compiler, lint, and DMR are all correct as far as this issue
is concerned.

I think the referenced publication should look for a programmer who knows
his/her/its C better than this one.  Or maybe change their name to
"Unprofessional".
--
long tloc = 507314353L;
	Roger Noe			ihnp4!uniq!rjnoe
	Uniq Digital Technologies	rjnoe@uniq.UUCP
	28 South Water Street		+1 312 879 1566
	Batavia, Illinois  60510	41:50:56 N.  88:18:35-