13 ms·
It is not correct. The array length is still there, what is happening is that you are implicitly asking for only a pointer to the first element of the array bec
by Arch-TK 4y ago
It is not correct. The array length is still there, what is happening is that you are implicitly asking for only a pointer to the first element of the array because of the context in which it is used. You did not ask for its length. The language has no way of passing an array itself by value. You could have asked for a pointer to the whole array but you didn't. When you are using an array in the context in which it is not an operand of the sizeof operator, the unary & operator, and not as a string literal used to initialise an array, then the expression which forms the use of the array involves an implicit conversion which produces a pointer to its first element.
You might think it's pedantic, but we're talking about C, it is important to be clear in language used to talk about C as it's an unforgiving language.
There is an untold amount of confusion surrounding how arrays work in C at least in part because of silly wording like "decay".
As a final note: When you write "f(foo.bar)" to call "f" while referring only to the "bar" field of the struct "foo" you are not losing "foo" and it is not "decaying" solely because the function which receives the result of the expression which formed the first argument of its invocation only sees the "bar" field of "foo". And now I'm not saying that it's a conversion either, but the point still stands. If "f(a)" where "a" is an array involves decay then so does array indexing or accessing a struct field.
- WalterBright 4y ago> The array length is still there If it was, we wouldn't be having this discussion and array bounds checking would have been added to C compilers 40 years ago.
- Arch-TK 4y agoCan you explain then, when I write: struct s { int bar; int baz; } foo = { .bar = 5, .baz = 6, }; f(foo.bar); Has "foo.baz" decayed? If the answer is no then you have an answer for why there is no decay involved in the implicit conversion. The fact the function does not receive the array size does not mean that decay has happened. That being said, nothing I just wrote wasn't in the comment you replied to, so maybe explain what it is from that comment that you didn't understand about my argument for why "decay" is simply the wrong word for what is happening. Also: This has nothing to do with array bounds checking. Also: Given the nature of the C language, I would find it surprising if compilers 40 years ago would have implemented bounds checking irrespective of if the language started out with either fat pointers or some other way of carrying the size of a specific array around with a pointer to its first element.
- erik_seaberg 4y agoK&R C could only pass scalars, so structs were rejected while arrays became pointers. ANSI C didn’t dare change the legacy behavior when passing an array, but if you embed the array in a struct and pass that, it works correctly.
- Arch-TK 4y agoYes, but I don't see how this has anything to do with what I wrote.
- mhh__ 4y agoThe length is there but you can't access it.