[A89] Re: A problem

[Prev][Next][Index][Thread]

[A89] Re: A problem


> testmap isnt an interger
> that should work, tell me if it does

Disclaimer: Every time I think I'm right about something, either Zeljko or
Patrick Davidson (or both) states that I'm wrong and corrects me.  I'll wait
for confirmation before being 100% certain of what follows, although I'm
pretty sure it's accurate =)

Sorry, but that isn't the problem in this code.  First of all, in TI-GCC, by
default int and short are equivalent (I believe that this can be changed via
a command-line option).  Second, creating an array should work regardless of
whether or not its type is the implementation-defined int or specified to be
short or long.  Third, we don't know what type he desires that data to be,
but int might very well be it (especially in this code, where the int and
short are identical).  I'm not quite sure what your reasoning was with that
correction, but if you're willing to explain it, I'd be interested in what
it is if you'd like a better explanation of why it isn't the problem here.

I'm pretty sure that the problem is that the original poster is trying to
create an array of a dynamic size; that is, the size of the array is
specified by the variables x and y.  In C, this is one of those things that
seems logical from a high-level programmer's point of view, but not from a
compiler's point of view.

If you'll recall, in C, all variables created at run-time -- that is, all
non-const, non-static, non-global variables -- are stored on the stack.  The
compiler will know exactly how "deep" in the stack this information is, and
the compiled code will actually refer to each value by its offset from the
top of the stack.  But if the array is variable-sized, then the space it
takes up on the stack is unknown, and thus the compiler doesn't know how
deep in the stack all of these variables are at run-time.  Because of this,
it cannot compile the C code into valid assembly/machine language.

Instead, dynamic arrays must use storage space from the heap, not the stack.
But the C compiler doesn't know how to use the heap itself (unlike in C++,
which has keywords such as new and delete), so the stack space must be
reserved via system calls.  In C, this is typically one of malloc, calloc,
etc.  TI has its own heap functions in ROM, but using TIGCCLIB you can use
the standard malloc.

The size of the array will, in this case, be (sizeof(int)*x*y) bytes.  (It's
not always that simple if you need to worry about, say, an odd number of
chars per row and their alignment in memory.)  Thus, in order to reserve the
amount of memory necessary and create a pointer to it, we'll need to use the
following code:

    int* testmap = (int*)malloc(sizeof(int)*x*y);
    if (testmap == NULL)
     {
        /* handle error: memory here */
     }

testmap can then be accessed using pointer notation.  ie, testmap[h][k] can
now be accessed as:

    *(testmap+(h*y+k))

I'm sure that Zeljko has some useful-but-dirty hack that would let you
access the map using array notation, but since I haven't quite figured out
how he does some of those yet, I'll wait and see his answer.

    -Scott
Follow-Ups: