array in function parameter declaration

Hi,

this is from the C standard document:

Quote:

---

If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression.

---

I thought just a normal constant expression would describe this behaviour.....

In other words, what is the difference between

Code:

---

int foo(int a[static 10]) { ... }

---

and

Code:

---

int foo(int a[10]) { ... }

---

then?

Thanks for helping me with this.

kind regards,

I haven't actually read the C standard, and this seems like a good reason not to ;)

I don't think there is a difference (who says there has to be?). That would explain why

Code:

---

int foo(int a[static 10]) {

---

is probably never used.

I think that what the 1999 edition of the C standard means is that given this function:

Code:

---

void print(int numbers[static 10]);

---

You would not be allowed to do this:

Code:

---

int my_numbers[5];
print(my_numbers);

---

The actual argument of print() is a pointer to the first element of the my_numbers array, but my_numbers is not "an array with at least as many elements as specified by the size expression", since my_numbers has 5 elements but the size expression specifies 10 elements.

That said, I was not able to get the MinGW port of gcc 3.4.5 to emit any error or warning despite compiling with the -Wall -pedantic -std=c99 options.

EDIT:

Quote:

---

Originally Posted by MK27

I don't think there is a difference (who says there has to be?).

---

The 1999 edition of the C Standard, assuming that I interpreted it correctly.

Quote:

---

Originally Posted by laserlight

That said, I was not able to get the MinGW port of gcc 3.4.5 to emit any error or warning despite compiling with the -Wall -pedantic -std=c99 options.

---

gcc 4.3.2 with all those switches totally respects this as well.

Code:

---

#include <stdio.h>

void testfunc (int a[static 20]) {
        int i;
        for (i=0; i<10; i++) printf("%d\n",a[i]);
        a[7]=2000;
}

int main () {
        int b[10]={11,21,22,23,14,51,66,17,88,91};       
        testfunc(b);
        b[5]=0;
        puts("______________");
        testfunc(b);
        return (0);
}

---

Quote:

---

Originally Posted by MK27

gcc 4.3.2 with all those switches totally respects this as well.

---

As in it emits a diagnostic?

Quote:

---

Originally Posted by laserlight

As in it emits a diagnostic?

---

Used on the above:

Code:

---

[root~/C]  gcc -Wall -pedantic -std=c99 test2.c
[root~/C] ./a.out

---

It's the same regardless of the presence/absence of "static". By "respect" I meant the code and not the standard.

Quote:

---

Originally Posted by MK27

It's the same regardless of the presence/absence of "static"

---

Ah, then gcc 4.3.2 is also non-conforming in this respect, assuming that my interpretation is correct. I tried passing a pointer to the second element, but gcc 3.4.5 still accepts the argument without a diagnostic.

Again, I haven't read the C standard, so I don't know if

Quote:

---

shall provide access to the first element of an array with at least as many elements as specified

---

would mean that the compiler should check. Then there doesn't seem to be a point to the whole statement, or even that it is slightly misleading because it implies a difference, but unless that difference is spelled out (eg. "in contrast to") it is still only implied.

And (computer) people are like that on a regular basis, when really they should have a greater sense of responsibility to avoid obfuscation or ambiguity....

thank you for your thoughts about this.

I really think there is a difference in the meaning, even if every existing compiler ignores it. Maybe it's a kind of "dead feature"...

If there would be no difference then there would be no need for the "static" at all because it has no other function than the quoted one.

I suspect GCC not to implement this so trial-and-error approach finding the meaning will maybe fail.
For example the

Code:

---

int foo(int p[*])

---

thing isn't implemented by GCC too... but at least in this case we get a warning.

Ok, i finally found something which explains it:
http://publib.boulder.ibm.com/infoce...rray_index.htm

Basicly it's a compiler hint for optimization. We tell the compiler that the array passed to the function has at least the defined number of elements. The compiler guarantees defined behaviour only if we abide the restiction we made. So it is in the programmers responsibility not to pass an array to the function with less than the defined number of element.

To actually cause the undefined behaviour, i think we have to set certain optimization flags of the compiler.

Quote:

---

To actually cause the undefined behaviour, i think we have to set certain optimization flags of the compiler.

---

This is not quite true. It may work perfectly well with all compilers in the world and still is undefined behaviour. Undefined behaviour doesn't mean the program crashes, it just tells you to not expect it to work. The compiler is free to do anything in this case, ranging from the intended behaviour to destroying the universe.

Quote:

---

Originally Posted by laserlight

Ah, then gcc 4.3.2 is also non-conforming in this respect

---

Also not true. An implementation may actually completely ignore "static" in this context (which I think is what gcc does at the moment) and would still be standard-conformant, i.e. cause undefined behaviour. See my comments on "undefined behaviour" above.


On a personal note, I reject language features that are supposed to support optimization. In this particular case, the compiler is much better at determining the minimal size of the function argument because he knows of every function invocation. If the compiler can't tell, the programmer doesn't as well. The programmer may even prevent the compiler from performing the best possible optimization. More generally, the programmer can only make guesses about the optimal behaviour in a specific case, while the compiler knows for sure (or at least can be taught).

Greets,
Philip

Quote:

---

Originally Posted by Snafuist

Also not true. An implementation may actually completely ignore "static" in this context (which I think is what gcc does at the moment) and would still be standard-conformant, i.e. cause undefined behaviour.

---

Indeed. I deduced that gcc was nonetheless conforming due to these two statements in section 4 of the 1999 edition of the C standard:

Quote:

---

A strictly conforming program shall use only those features of the language and library specified in this International Standard.

---

Quote:

---

A conforming hosted implementation shall accept any strictly conforming program.

---

However, I was not convinced. Now that you point out that undefined behaviour is involved (and that is directly supported by paragraph 2 of the same section), I am convinced, since no diagnostic is required for undefined behaviour.