Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!hadron!jsdy@SEISMO.ARPA
From: jsdy@SEISMO.ARPA
Newsgroups: net.lang.c
Subject: Re:  sizeof and array parameters
Message-ID: <6802@brl-tgr.ARPA>
Date: Thu, 27-Dec-84 20:03:12 EST
Article-I.D.: brl-tgr.6802
Posted: Thu Dec 27 20:03:12 1984
Date-Received: Sat, 29-Dec-84 03:03:57 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 29

> #define ARRAYSIZE 4
> 
> readarray(fd,a)
>  int fd;
>  int a[ARRAYSIZE];
> {
>     read(fd,a,sizeof(a));
> }
>                        ... sizeof(a) was 4 (the size of a pointer) ...
>  ... I feel that sizeof should have returned 16.  ...
> The question of course, is whether one should view paramter "a" as
> an array, or just a pointer.  My view is that it is an array, and
> should be treated as such.  ...  since it has a dimension
> there is no justification for semantically treating "a" as if it were simply
> a pointer to integer.  Obviously the representation is still a pointer
> to integer, but the major justification for "int a[]" being equivalent
> to "int *a" is simply that we don't know the true size of "a".  ...

There's some justification to this.  But it is generally understood
(K&R 5.3 par.9, e.g.) that the parameter can be handled as either a
pointer or an array.  Everything you can do to an array, you can do
to a pointer, but not vice versa -- so parameters are in fact imple-
mented as pointers.  (E.g., ++a is legal even above.)  It doesn't
matter what convenient legal fiction you are using at the moment.
The compiler must recognise 'a' as a pointer:  if it treats it as
an array, you will be climbing the stack instead of dereferencing
the pointer.

Joe Yao		(UUCP!seismo!hadron!jsdy / hadron!jsdy@seismo.ARPA)