allocating arrays

[David Herron, NPR Lover]

[My mailer doesn't know anything about dg_rtp.UUCP, could you please
let uucpmap at cbosgd know of your existance????]

In article <350 at dg_rtp.UUCP> you write:
>> allbery at ncoast.UUCP (Brandon Allbery)
>
>> | Consider an array of 15 pointers to arrays of doubles:
>> |     double (*parray[15])[];
>> | The following code to 'malloc' the actual double array barfs on Microsoft 'C',
>> | with a 'different levels of indirection' warning on the '='.
>> | The code passes through LINT, and compiles OK on UN*X 5.2
>> |     char    *malloc();
>> |     parray[0] = (double*)malloc((unsigned)sizeof(double)*75);
>
>> double (*parray[15])[]; means:
>>       an indefinitely-sized array of (or a pointer to)
>>               an array of 15
>>                       (double *)
>
>Wrong.  It means just what the original poster said it meant.  It is an
>array of 15 pointers to arrays of double.  What the original poster is
>mistaken about is that lint doesn't complain about the example.  In
>particular, given this example

I respectively submit that you're full of it and that Brandon is correct.

Using []'s in a declaration is SIMILAR to declaring a pointer, 'cept
that the pointer is an internal constant in the compiler, and if you 
fill in a value inside the []'s it allocates some space.  A stumbling
point is when a [] declaration is an arg to a function, THAT gets
translated to a * declaration...

Some examples:

	char a[] = "this is a character string\n";
	char b[];

(oh, they're both external decl's)  Tell me tho, what USE is a 
the declaration of b[]????  Translating the decl to *b isn't
doing what I SAY, and (on Unix anyway) what I SAY is what I MEAN.
Anyway, compiling I get:

	Undefined:
	_main
	_b

_main is undefined because I don't have a main() obviously.
_b is undefined because it knew that somewhere there's a b[]
and made a reference to it.  

Modifying it to read:

char a[] = "this is a character string\n";
main()
{
	char b[], *c;
	char *malloc();

	printf("b = 0x%x\n", b);
	/* b = */ c = malloc(5);
	printf("b = 0x%x, c = 0x%x\n", b, c);
}

produces:

	b = 0x7fffe880
	b = 0x7fffe880, c = 0x2800

(BTW, this is a Vax running 4.2BSD, and we have the "hated" pcc,
a value like the one for b is a stack location)

Originally I had the b[] decl by itself and the compiler swallowed it.
(I have no idea what the compiler thought I wanted to do with a b[]...)
But it didn't like it when I had the b = uncommented...  (which is
what I'd expect).  Looking at the assembler output, b[] is a pointer
to the top of the stack but there's no space allocated to it.  There's
only space allocated for the *c.  

>
>        void f(){
>            double (*a[15])[];
>            char *malloc();
>            a[0] = (double *)malloc((unsigned)sizeof(double)*75);
>        }
>lint (on our system at least) says
>        warning: illegal pointer combination
>            (4)

Right.  the pcc says "illegal lhs" or something to that effect.  Which
is correct... there's no space allocated to your a.

>
>I grant you, this isn't very informative, but lint *doesn't* like it,
>that much is certain.  Let's run a more blabbermouth tool over it.
>
	... [deleted, for the sake of brevity, some very interesting output]
>
>As you can see, this is an attempt to assign a pointer-to-double to a
>pointer-to-array-of-double.  In this case, it is easy to tell that this
>is what is going on even without blabbermouth typecheckers.  The
>declaration of a is of the form (*[])[], making the type of a[0] (*)[],
>a pointer to an array.  The cast of the return value of malloc was
>simply *, that is, a simple pointer.  If you want your compiler to shut
>up, you should make the cast read (double (*)[]).  When the cast is
>changed in this way, lint no longer complains.  Changing the cast to
>(double **) naturally still causes complaint.

er... where did you get that program?  I agree with it somewhat EXCEPT
it's not making a distinction about CONSTANT pointers a la arrays. It's
an interesting program nonetheless...

I agree with you that the compilers need to produce better error messages.


-- 
David Herron,  cbosgd!ukma!david, david at UKMA.BITNET, david at uky.csnet