Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!rti-sel!dg_rtp!throopw
From: throopw@dg_rtp.UUCP (Wayne Throop)
Newsgroups: net.lang.c
Subject: Re: Pointers and Arrays
Message-ID: <432@dg_rtp.UUCP>
Date: Mon, 7-Jul-86 14:53:15 EDT
Article-I.D.: dg_rtp.432
Posted: Mon Jul  7 14:53:15 1986
Date-Received: Tue, 8-Jul-86 07:32:01 EDT
References: <1242@ncoast.UUCP> <418@dg_rtp.UUCP> <1267@ncoast.UUCP> <2201@umcp-cs.UUCP> <2206@umcp-cs.UUCP>
Lines: 81
Summary: picky, picky, picky (interesting nit, though)

> chris@umcp-cs.UUCP (Chris Torek)

Good article overall.  However, I have a nit to pick with one of the
examples:

>         int day_tab[2][13] = { ... };
>
> the following are type-correct calls:
>
>         f2d(p) int (*p)[13]; { ...  }
>
>         f1d(p) int *p; { ...  }
>
>         proc()
>         {
>                                         /* argument types: */
>                 f2d(day_tab);           /* pointer to array 13 of int */
>                 f2d(&day_tab[0]);       /* pointer to array 13 of int */
>
>                 f1d(day_tab[0]);        /* pointer to int */
>                 f1d(&day_tab[0][0]);    /* pointer to int */
>         }

There is one problem here.  The expression (&day_tab[0]) is illegal.
Given this simplified example:

     1  int aa[2][3];
     2
     3  void f1(pa) int (*pa)[3]; { }
     4
     5  void f2(){
     6      f1(aa);
     7      f1(&aa[0]);
     8  }

lint has this to say (among other things):

        (7)  warning: & before array or function: ignored

Granted, things are very strange here, since the [] operator is always
supposed to yield an lvalue.  However, as Chris pointed out, values of
type ([]) are always coerced to expressions of type (*) in all contexts
except sizeof.  Thus, the subscription yields a (potentially) lvalued
expression of array type, and it is coerced to a non-lvalued pointer
type, and thus the address-of is illegal.  (I think.)

Note well: The problem isn't with the type of aa.  Lint is *not*
complaining about the fact that aa follows the "&".  This peculiarity
arises because (aa[0]) has type (int [3]), and is immediately coerced to
an expression of type (int *) in all contexts except sizeof.  Thus,
while (&aa[0]) is illegal, (&aa[0][0]) is quite legal indeed.  Of
course, the latter operation doesn't yield a pointer of the correct type
to be passed to function f1 above.

--
>       `You can hack anything you want,
>        with pointers and funny C . . .'

Sung to "Alice's Restaurant", I presume?

(We'll wait 'til it comes around, then join in...)
(That's what we're doing now... waiting for it to come around...)
(Here it comes...)

        You can hack anything you want,
        With pointers and funny C.
        You can hack anything you want,
        With pointers and funny C.

        Dive right in, if you feel the need,
        It's a great language but it's gone to seed.
        You can hack anything you want,
        With pointers and funny C (Excepting Ritchie...)

(That was pittiful.)

--
"I wanna *HACK*!  I wanna *HACK*!!!
 I wanna feel *BITS* between my teeth!"
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw