Thread: array in function parameter declaration

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:

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.

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);
}

Originally Posted by MK27

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

As in it emits a diagnostic?

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.

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

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.

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:

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

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.