Hacker News Reader

Comment by acconsta | Hacker News Reader

Does anyone know why array arguments decay to pointers?

Because that's how the machine sees C arrays. It would take an extra (invisible) parameter on the stack to implicitly pass the array size into the function, a thing which is very much against the spirit of C.

The only real surprises/magic in C are things like:

  - addition/subtraction on typed pointers has an implicit multiply by sizeof(type)
  - type conversion between floats and ints

But the size of C89 arrays is fixed and known at compile time. Why would the length need to be passed?

It's not necessarily known by the caller, since the array might be declared with an unspecified size and defined in a different translation unit.

"might" is the key word there though. What if the array has a statically known size, like the code sample in the email?

I suppose it could just be for consistency.

> Because that's how the machine sees C arrays. It would take an extra (invisible) parameter on the stack to implicitly pass the array size into the function, a thing which is very much against the spirit of C.

It would only require a separate parameter if you needed to pass arbitrary-sized arrays. In this example, if the prototype contains the array size:

    int foo(char array[30]);

It would not be difficult for the compiler to only allow arrays of that length to be passed as parameters, and no invisible parameters are necessary, assuming also that the function implementation made the same assumption of array length.

Developers who handle arrays of arbitrary length tend to already encode a length parameter, it's this case where it looks to the developer like they are encoding a length value that is the deceptive/problematic case.

> It would not be difficult for the compiler to only allow arrays of that length to be passed as parameters

It would be extremely difficult for the compiler, without changes to the C spec and most ABIs, to simultaneously provide that protection for heap-allocated objects, for example:

    foo(malloc(30));

> Developers who handle arrays of arbitrary length tend to already encode a length parameter, it's this case where it looks to the developer like they are encoding a length value that is the deceptive/problematic case.

The most common arrays of arbitrary length in C programs are almost certainly C "strings" which are usually 0-terminated instead of including a length value.

This is one of the many uses of the static keyword in C99:

  void ten(char foo[static 10]) { }

  void generates_warning() {
    char foo[3];
    ten(foo);
  }

This causes clang to emit the following warning:

> warning: array argument is too small; contains 3 elements, callee requires at least 10

The warning is true - it is "at least" 10:

    char ten(char foo[static 10]);

    char ten(char foo[static 10]) { return foo[1]; }

    void generates_no_warning(void);

    void generates_no_warning() {
        char foo[30];
        ten(foo);
    }

    int main() {
        generates_no_warning();
    }

Modified also so it would build cleanly with -Weverything -Werror

It avoids stepping on memory elsewhere in the program though. My personal preference for C99 and above is to pass the length as a parameter.

    int do_stuff(size_t len, int64_t arr[len]);

It still suffers from the pointer decay problem, but it at least forces whoever is reading/writing the code to acknowledge the length.

How does that parse? I thought static was only a storage class.

When extending the language, the committee will often try to re-use existing reserved keywords to avoid colliding with a variable name in someone's code.

Thus we have yet another overloading of "static" in C, the use of "auto" in C++11 (which worked out quite well), and interesting type names such as "long long" in both.

When the committee breaks this rule (think nullptr in C++11) they first must choose a name which is suitably rare (and often a bit clunky as a result), they then scan for that name in large code corpuses, and evaluate how much work they are making for the maintainers of any codebase that's going to be compiled against a new compiler (and which may need to be modified to do so).

Some languages (I'm thinking JS specifically) have keywords that are not in use but are still reserved in case they may be useful in the future.

In this case, the size is specified as a compile-time constant, however, which seems like it could work. All it would do is change the semantics of sizeof(), really.

Also, I am doubtful whether it would really be a problem to have "invisible" parameters. C doesn't even specify a stack as I remember it, and compilers are certainly free to pass as many function parameters in registers as they are able to.

It is an ABI change.

True, someone else pointed out that this could all be done as compile time checks, which would have no runtime/ABI impact.

There are interesting stories from the early days of C when it was first codified that say a lot about the whys and hows of the language that we have today. In particular I'm thinking of the fact that the compiler and what we now think of "compiler warnings" came from two different warnings (cc vs lint). This is because the C compiler was the largest C program and generally took every bit of memory available to do it, there was no room for any kind of sanity checking on that code. I've heard it said that to include a new feature "n" in the language, they generally had to rework at least some of the existing compiler code with feature "n-1" to simplify/shrink it enough to fit the new feature.

In that kind of environment you get a language with very little input checking, beyond the rules of the grammar itself (which was as small as possible).

Well, the information isn't copied... so if you modified the incoming array you modify the original, so in that sense it has to be a pointer. Arrays and pointers are analogous in C except when they are declared, as there is an implicit allocation of information. Since we don't want this when it comes to array arguments, it simply decays.

In C (and in all other languages I can think of), an array is actually a pointer to a bunch of memory. Indexing into the array calculates offset from the array pointer, and grabs the item at that offset.

FYI the equivalent Go code would actually copy the whole array on the stack, and so it would be valid if possibly inefficient depending on the size of the array.

...and for anything larger than a small fixed-size array (like the example), you'd avoid data-copying overhead by passing a slice, which is a bounds-checked bundle of pointer and length.

Array is not a pointer. Your description of indexing is not correct, neither is the phrase "array pointer" you invented. The machine code produced will calculate the offset differently for a pointer and an array.

Let me clarify with an example. Suppose you have an array:

  int a[10]

There is a section of memory of size sizeof(int) * 10 somewhere, and the variable a is a * int that points to that section. When someone does this:

  int x = a[2]

It is equivalent to:

  int x = *(a+(sizeof(int)*2))

When I said "array pointer" in my previous comment, all it meant was the memory address that the variable (which is an array) points to (in the example, the variable "a")

Edit: missing paren

a is a label, or an alias of a memory address. It is not a pointer. ( Your third example has a mistake, the correct increment is: a+2, because pointer arithmetic increments in object size not byte size )

Read this:http://eli.thegreenplace.net/2009/10/21/are-pointers-and-arr...

Interesting read. Thanks :)

Because as Linus stated: "array arguments in C don't actually exist"

The bracket notation ex: myarray[2] is actually just a sugar syntax for: * (myarray+2)

An array is nothing more than an address and a (hopefully) know length. Not really a "data structure" or object by no means.

You could definitely roll your own though with something like:

  struct  {
    char * arr,
    int size
  } my_struct;
  
  for(int i = 0; i < my_struct.size; i++){
    printf('%x', my_struct.arr[i]);
  }

  ect,

Yeah. But why is that the behavior specified by the standard?

Because C designers decided to ignore other saner systems programming languages and thought it was a cool idea to do that.

No, C wasn't the first systems programming language used to write OSes.

Because the compiler gets the length of an array from its declaration. However, inside a function the compiler cannot tell the size of the actual array parameter.

If I write:

void example(int a[10]);

Why can't the compiler tell a is an int array of size 10 instead of a pointer?

sizeof(a) is sizeof(int*) in your example because of the C standard: That is to say this is a bug in the standard, and not a bug in any particular compiler.

Yes, but why does the standard have that bug?

Probably because the compilers that were standardized had that bug.

There is no strict difference between a pointer and an array (of any size) at run time in C. Arrays are just pointers to a section of memory, and it's up to the programmer to communicate how big that section is.

There are whole separate chapters describing arrays and pointers in the C Standard. This is by definition a strict difference. You should read those chapters and please stop spreading this beginners misconception of C.

Because a is a pointer and not an array. That is by design.

When you pass an array to this function you are not copying the entire array, C is pass by value, therefore you must pass a pointer. In fact a behaving like an array would be lying to the programmer since you didn't make a copy of the array.

You can pass structs by value. Why not arrays?

Your answer is merely a simple online search away.

What's weird is five hours after asking that question, no one has provided a reasonable explanation of why C requires arrays to become pointers on function boundaries.

My "online search" found Walter Bright, who knows a thing or two about C compilers, wondering the same thing:

https://news.ycombinator.com/item?id=7572011

Improve your searching capabilities.

https://programmers.stackexchange.com/questions/245602/why-c...

( https://stackoverflow.com/questions/7454990/why-cant-we-pass... )

And partially this thread.

As for Walter; Stop using C like you want it to be used, and instead how it is meant to be used. The article takes a strawman position. Anyone who takes their time and learns C, knows that arrays decay.

So it comes down to historical compatibility with B? Wow.

Reply on news.ycombinator.com