Hacker News Reader

Comment by ScottBurson | Hacker News Reader

Yes. As I've long said, C does not have arrays. It has pointers and notations for initializing memory, but it does not have arrays.

There are actually two problems here. One is the absence of bounds checking. The other, which is related but technically orthogonal, is the hole in the type system: an array is not an object. It's been true since Unix v7 that you can pass or return a struct by value, but you can't pass an array by value unless you wrap it in a struct.

The type system also makes no distinction between a pointer to a single object and a pointer into an array of objects. I've worked on static analysis tools that try to find potential buffer overflows, and this turns out to be a surprisingly big problem. One has to do a global dataflow analysis just to discover which pointer variables could ever point at array elements.

View on HN

It would help if you define what you mean by "object". This term has a definition in the C standard by which arrays are unquestionably objects. It is true that you cannot pass or return them by value, but that does not mean they are not objects, that means the ability to pass or return things by value is not a property of objects.

About the singular vs array question: this is true but just a special case of the absence of bounds checking, is it not? C's approach of allowing e.g. "int i;" to be addressed as if it were an array of length 1, allowing construction not just of &i but also &i+1 as pointer values, is valid and sometimes useful, but you have to make sure you never access *(&i+1). That's the same problem as how given "int a[2];", accessing a[2] is not valid, as far as I can see.

What GP means is "there are no array expressions in C's syntax". You can't copy them or assign them, and I'm not sure that they are part of any kind of "type system" in C (although some compilers have a notion of array type internally, which is obvious from their error messages).

That's just not true, there are array expressions, and arrays are part of the type system. I give him more credit than that. (The "you can't copy them" is technically untrue as well but that is just because of sloppy wording.)

You're right, I forgot about compound literals, which were introduced in C99 and which are a rarely used feature.

But I guess my statement that "C doesn't have array expressions" was true before the advent of C99. And that's also why array decay made even more sense back then. (It still makes a lot of sense today IMO).

I didn't mean compound literals, I do not really see how they change things here, I meant that there are a few cases where arrays don't decay to pointers, and supporting those requires compilers to make arrays a part of the type system. Example: given "int a[3];", how else would you compute (&a+1) ?

To me, the question is what is actually "the type system" and what is "the allocation system" or whatever else aspect of implementing a compiler.

So determining the type of "&a" is not an issue, it's just one case in determining the type of a C expression (look up the object "a", is it an array? The type of the expression is a pointer to the array element type).

This is not a special case, at least not more special than how to determine the type of the expression "a", or "1".

No array type needed.

Are you aware that given int a[3];, (&a+1) and (a+3) denote the same address? If you are, how can that possibly work if as you suggest, &a and a are indistinguishable to the compiler, that they are both seen as a pointer to int?

That came quite honestly as a huge surprise to me. I've never seen this before. Thanks for the heads up!

Reply on news.ycombinator.com