[A89] Re: A problem

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

[A89] Re: A problem


> >Interesting.  I just read this entry in the FAQ, but keep in mind that
this
> >is a _GCC extension_ and not _ANSI C_.
>
> Could you explain why? I still don't fully understand how it works, so why
> would this not be valid in ansi c?

hmmm, notice that I can reverse that and it makes sense for me:

"Could you explain why? I still don't fully understand how it works, so why
would this be valid in GCC?"

Actually, the issue here is this line:

    int (*testmap)[x]= NULL;

Notice that when you're declaring the array here, one of the dimensions is
still a variable (x).  GCC is a very intelligent compiler, and one of its
"extensions" upon the C standard is that it's smart enough to handle that (I
wish I knew how the compiler designers worked that out).

But ANSI C, the "standard," says that when you declare an array, all
dimensions must be constant.  While many compilers have at least a few
extensions to ANSI C, but these extensions are not standardized.  I'd bet
that the vast majority of C compilers would see that code and issue an
error.

Not that you shouldn't use this great feature when it's available to you;
I'm just cautioning you that should you ever need to use a compiler other
than GCC (ie, the Sierra compiler TI uses in the SDK), this won't work.  I
don't think you should be too concerned about this now =)

> No i wasn't. That was the problem with it. passing it via char fn []
didn't
> need a null byte, but if they are the same, why did it work without one.

That's not true; char fn[] still needs a null byte at the end.  I asked that
because if you used pointer notation rather than array notation in the main
body of the program, you could wind up with something like this:
    char* fn;
    ReadInFileNameFunction(fn);
    CallTheProblemFunction(fn);

Since no space is reserved for fn there, you'd be overwriting some random
point in memory.  That same code would be valid if you used "char fn[9];"

Try this out:  take the code that works, and compile it using the exact same
code except for that function's prototype and definition; in those, use
"char* const fn" -- then see if that works.  They really _are_ identical
here (and they are in all but a few rare instances; I think Zeljko pointed
me to a doc on that once).

    -Scott
Follow-Ups: