deb@gt-eedsp.UUCP (05/27/87)
Perhaps this is a stupid question, but...
If I have a procedure in the same file that it's called from I get the
one array dimension as given by 4.3's version of DBX. When I place
it in a separate file, DBX reports a different dimension!
For example: (same file)
#include <stdio.h>
#define MAXOUTSIZE 318
#define MAXFILTSIZE 62
main()
{
static float X[MAXOUTSIZE][MAXOUTSIZE]; /* input image */
.../* other decls, etc. */...
writearray(X, (dim + L - 1));
}
writearray(a, size)
float a[MAXOUTSIZE][MAXOUTSIZE];
int size;
{ /* body */ }
(dbx) whatis writearray.a
array[0..62] of float *a;
If writearray is in another file, with MAXOUTSIZE defined as above:
(dbx) whatis writearray.writearray.a
array[0..MAXINT] of float *a;
^^^^^^of course, it doesn't say 'MAXINT', but the
integer there is indeed MAXINT (unsigned on
a Vax 11/780)
Neither is correct! In the first, it's too small, in the second it's
much greater than necessary. Is this dbx that is messing up, or am I
missing the point entirely??? Maybe it's important to mention that
I'm running 4.2BSD(BRL)...just have the 4.3 version of dbx since it
handles fortran better than the old one.
Normally, I wouldn't really care what dbx says, but the printf's in
writearray die when malloc'ing in the latter version, so I'm quite
sure somethings terribly wrong! [Note: I have checked all the
declarations, etc...I know I haven't made a typo along the way.]
Thanks for any insight you can offer!
Deb Jackson
--
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332
(404)894-3058
uucp: ...!{akgua,allegra,hplabs,ihnp4,seismo,ulysses}!gatech!gt-eedsp!deb
internet: deb@dsp.ee.gatech.EDUgwyn@brl-smoke.UUCP (05/28/87)
In article <40@gt-eedsp.UUCP> deb@gt-eedsp.UUCP (Deb Jackson) writes: > static float X[MAXOUTSIZE][MAXOUTSIZE]; /* input image */ > writearray(X, (dim + L - 1)); > writearray(a, size) > float a[MAXOUTSIZE][MAXOUTSIZE]; >(dbx) whatis writearray.a > array[0..62] of float *a; >(dbx) whatis writearray.writearray.a > array[0..MAXINT] of float *a; >Is this dbx that is messing up, or am I missing the point entirely? Both. "Dbx" is hopelessly confused... What you need to realize is that your invocation of writearray() has as its first actual parameter the NAME of the array. In C, the name of the array (in most contexts) is converted to a pointer to the first element of the array (which in this case contains 1-dimensional arrays as elements). You have not passed the data bits themselves to the function, but rather a pointer that can be used to locate them. Because of this characteristic, the formal parameter in the function, which (unfortunately) Dennis decided to allow one to write as though it were the actual array declaration, is converted to a pointer to the first element so that it might as well be written: writearray(a, size) float (*a)[MAXOUTSIZE]; /* this is the SECOND dimension */ or, alas, the special-case syntax: writearray(a, size) float a[][MAXOUTSIZE]; There is no way (short of embedding the array in a structure) to pass the data bits themselves directly into the function as a parameter; there isn't even a syntax for that, given the C meaning of the name of an array. If I were designing C (assuming I could, which isn't realistic), I would require the first of the two equivalent forms I just gave as the only correct formal parameter declaration (modulo extra grouping parentheses), instead of supporting the "convenient" syntactic sugar that permits your original example. However, we're now stuck with the decision, so I recommend that you code the form I suggest, to make patently clear exactly what the type and meaning of the parameter really is. That will reduce confusion.
chris@mimsy.UUCP (Chris Torek) (05/29/87)
In article <40@gt-eedsp.UUCP> deb@gt-eedsp.UUCP (Deb Jackson) writes:
<... Is this dbx that is messing up, or am I missing the point entirely???
<Maybe it's important to mention that I'm running 4.2BSD(BRL)...just have
<the 4.3 version of dbx since it handles fortran better than the old one.
I daresay it is important: I cannot reproduce the problem under 4.3BSD.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chriskarl@haddock.UUCP (06/09/87)
In article <5898@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Because of this characteristic, the formal parameter in the function, which >(unfortunately) Dennis decided to allow one to write as though it were the >actual array declaration, is converted to a pointer to the first element ... I agree that this is unfortunate. >If I were designing C ... I would require the first of the two equivalent >forms I just gave as the only correct formal parameter declaration (modulo >extra grouping parentheses), instead of supporting the "convenient" syntactic >sugar that permits your original example. However, we're now stuck with the >decision, ... Are we? I propose that array declarations as formal parameters should be ILLEGAL in a function prototype. This is fully compatible with oldC, which doesn't have prototypes. This is the perfect time to make this change -- if false arrays are allowed in this standard, it will be very difficult to remove them later. This will not only reduce the confusion, but it may make it possible to introduce array copy (call by value, return by value, and assignment) in some future release of the standard. (I have some ideas on this; details on request.) ***** * \ * Say NO to false-array formal arguments in prototypes! * \ * Say YES to arrays as real objects! *f(int[]);* * \ * Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), * \ * The Walking Lint *****
franka@mmintl.UUCP (06/12/87)
In article <523@haddock.UUCP> karl@haddock.ISC.COM.UUCP (Karl Heuer) writes: |I propose that array declarations as formal parameters should be ILLEGAL in |a function prototype. I'll second the motion. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108