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)