allocating arrays

[Wayne Throop]

> david at ukma.UUCP (David Herron)
>> throopw at dg_rtp.UUCP (Wayne Throop)
>>> allbery at ncoast.UUCP (Brandon Allbery)
>>> | ???

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

[It has been done, long ago.  We are (finally!) on the latest maps.
 Also, my .signature shows a path to dg_rtp from mcnc, and mcnc is quite
 well known (being part of the backbone, I beleive).]

>>> | Consider an array of 15 pointers to arrays of doubles:
>>> |     double (*parray[15])[];

>>> 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.

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

I exasperatedly submit that I'm quite empty of it, and that Brandon is
as wrong as wrong can be.  Also, after saying I'm wrong, your examples
go on to support my position strongly, so you've succeeded in puzzling
me no end, as well as prolonging this discussion beyond it's natrual
span.

But meanwhile, long ago, in an address space far, far away....

                                  POINTER WARS

                                The Evil Empire
                                has attempted to
                             perpetuate the fallacy
                           that pointers are the same
                          thing as arrays.  The brave,
                       outnumbered, noble, correct, long-
                 suffering rebel alliance has always maintained
               that the Force keeps pointers and arrays distinct.
              Our hero (moi) has lived a peaceful existance on the
             out-of-the-way node dg_rtp for years, until finally an
            empire star destroyer (which insists that stars ("*") in
         declarations can be replaced by brackets( "[]")) finds dg_rtp
                    via the news network, and opens fire....

                    Let's listen in, as the battle begins...

> [Shhhh-Pfoooo...      Shhhh-Pfoooo...]

[You can't fool me, Darth Vader!
 I know that's you behind the life-mask!]

> 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...

Yeah, right, [] is just like a pointer, except that it isn't, really.
Give me a break.  A [] declaration always declares an array, and arrays
and pointers are *NOT* (I'll repeat for those who have trouble
understanding this concept: *NOT*) the same thing.  The fact that array
formal arguments must "actually" be pointers is no more significant than
the fact that character formal arguments must "actually" be integers.

And while declaring *anything* is to some degree similar to declaring
anything else, pointers and arrays are not really very similar.

> 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.

What's the big deal?  This says that "a" is an array 28 characters long
(unless I've counted wrong... which is the reason for this shorthand in
the first place), and storage for "a" is allocated in this file, and
initialized to the given string.  In addition, you are saying that "b"
is an array of unknown size, and storage for it is *not* allocated in
this file (that's why it can be of unknown size... the storage will be
allocated somewhere else). (What use is "b"?  My good sir, what use is a
baby?)  Given all this, is it hardly surprising that

> Anyway, compiling I get:
>         Undefined: _b

since you implicitly promised to allocate space for "b" somewhere else,
and then didn't do it.  So where's the strangeness?  How does all this
flapdoodle support your contention that "double (*parray[15])[]" isn't
an array of pointers to arrays of double?

[   Let me be clear about what "shorthand" I'm talking about above.  In
    C, the declaration
                char a[] = "ab";
    is shorthand for
                char a[3] = {'a', 'b', '\0'};

    (though there is some debate as to whether that "'\0'" should be "0"
    instead, or exactly what '\0' means (does it mean zero or ascii
    null?))

    This is *NOT* the same as the declaration
                char *a = "ab";
    which isn't shorthand for anything, and which behaves quite
    differently.  The array declaraction allocates storage of size 3,
    and initializes those three characters to the values given.  The
    pointer declaration allocates storage for one pointer (on our
    machine, of size 4), and initializes it to point at the first
    character of a constant array of size 3.  As I say, quite different.
]

> [another example, simplified:
>       f(){
>                char b[];
>                printf( ... b ...);
>       }   ]
> Looking at the assembler output, b[] is a pointer
> to the top of the stack but there's no space allocated to it.

Actually, the declaration of b is illegal, and our compiler complains
bitterly about it.  I assume your compiler treated it as a zero-sized
array.  I doubt that it treated it as a pointer, as you suggest.
(Interestingly, lint doesn't complain about it.  It certainly ought to.)

>> [verbose typechecker output, deleted]
> 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...

Well, the program is a typechecker that was locally written to check the
rules as laid out in Harbison and Steele, sort of the new testament to
K&R's old.  Sadly, I'm not currently at liberty to release it.

It is making all the distinctions it should.  It was created in essence
by going through H&S (as well as K&R), and translating the type rules
found there into checks performed against the parse tree of the input C
program.  Each error message is in fact related back to where H&S
justifies calling the construct an error.  I trust it a fair amount more
than I do lint (though, to my utter dismay, it didn't complain about
"f(){char b[];}" either... if anybody can justify why that should be
legal (as I say, our compiler complains bitterly), I'd appreciate a
message explaining why).

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

Good.  I hope you now also agree that compilers should keep the
differences between pointers and arrays straight.  Keep away from the
Dark side of the Force, and you can't go wrong.

I stress again, the declaration

        int (*a)[];

is *NOT* (i say) *NOT* (i say again) *NOT* the same as the declaration

        int **a;

and any entity that thinks they *are* the same thing is,
quite simply, mistaken.  Trust me folks... I'm right about this.  If you
think these two are the same, you simply haven't thought about it
enough.

--
"Luke... use the Force!"
--
"He's turned his targeting computer off!"
--
Stay tuned for the next exciting episode,

        The Umpire Strikes Out

Coming soon to a netnode near you!
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw