A nice, little known C feature: Static array indices in parameter declarations

http://hamberg.no/erlend/posts/2013-02-18-static-array-indices.html

by ehamberg • 13 years ago

252 112 13 years ago

hamberg.no

vvhn• 13 years ago

great, just what we need - yet another overload of the static keyword :-).

matthavener2• 13 years ago

In C++, you can do this by passing the array by reference:

    void foo(int (&foo)[10]) {}

However, that is not "minimum of 10" but "exactly 10".

You can also get the size at compile time:

    template <size_t N> void foo(int (&foo)[N]) { int newarry[N+2]; }

I've used the above for something like this:

    template <size_t N> void safe_strcpy(char (&buf)[N], const char *src) { 
      strncpy(buf, src, N-1); 
      buf[N-1] = 0; 
    }

pyrtsa2• 13 years ago

And, by extending your second example, we can enforce the minimum array size with std::enable_if (C++11; boost::enable_if_c with C++03):

    template <size_t N>
    typename enable_if<(N >= 10), void>::type
    foo(int (&bar)[N]) { ... }

EDIT: Changed condition from N >= 0 into a more meaningful one. X-)

huhtenberg• 13 years ago

... and just as I was going to make a smart-ass joke about Boost probably having another contrived contraption just for that - there it is, already sneaked into the standard too.

pbsd• 13 years ago

The more readable C++11 version would use static_assert:

    template <size_t N>
    foo(int (&bar)[N]) 
    { 
        static_assert(N >= 10, "Array needs >= 10 elements!"); 
        ...
    }

chc• 13 years ago

This works with pointers in both C and C++. int (*foo)[10] is a pointer to an array of exactly 10 elements. The novel thing being pointed out in the OP is the "10 or more" aspect.

cliffbean• 13 years ago

That's true, until you forget and type foo[i] instead of (* foo)[i]. Of course, compilers will usually catch that mistake at compile time...

There'a an interesting analogy with structs here. K&R invented the -> operator specifically to obviate (* ptr).member. It's too bad that arrays took a different route through C's history and didn't manage to end up in a place where a similar convenience would make sense.

jmaygarden2• 13 years ago

I've never seen this before:

  void bar(int myArray[static 10])

Is that standard, and if so, how long has it been?

I also ran across this construct in a quick search [1]:

  void bar(int myArray[const])

[1] http://stackoverflow.com/questions/3693429/c-parameter-array...

ehamberg3• 13 years ago

From http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf:

6.7.5.3 point 7: “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.”

jmaygarden2• 13 years ago

So, it was added in C11?

UPDATE: Thanks. The 2005 date on the linked document threw me off.

nathell• 13 years ago

I thought I knew C.

niggler4• 13 years ago

What makes me wary of using these uncommon constructs is that someone editing code later may make a change based on a superficial understanding (and break the build)

ambrop72• 13 years ago

Much less likely than someone editing code later using his superficial understanding of C++ :)

shurcooL4• 13 years ago

This is one of the things that attracts me to Go (and developing tools for working with it, which requires parsing the language, etc.). It's much easier to keep the entire language spec in your working memory, because it all fits in http://golang.org/ref/spec.

frou_dh4• 13 years ago

I agree that it's a pretty clean language, but it still has oddities. For example, where in your linked spec does it address why the following trips a compile error?

    func foo(b bool) {
        if b {
            return
        } else {
            return
        }
    }

    func bar(b bool) int {
        if b {
            return 100
        } else {
            return 200
        }
    }

    func baz(b bool) int {
        if b {
            return 100
        }
        return 200
    }

    func qux(b bool) int {
        if b {
            return 100
        } else {
            return 200
        }
        panic("?")
    }

    // Error: function [bar] ends without a return statement

stusmall• 13 years ago

That's just because its young. The same could have been said for C in the long long ago. And honestly compared to most of whats out there, C is a tiny language. Give go time, it'll bloat ;)

Aardwolf• 13 years ago

C and even C++'s spec are still easier to remember than bash shell scripting imho. For bash shell scripting, I need to keep a document full of examples to copypaste from, otherwise it's always wrong on first try anyway!

matthiasv• 13 years ago

Unfortunately, gcc does not warn. I can pass a NULL pointer and arrays that are too small. But on the other hand, there is very little use, because arrays usually contain an arbitrary number of elements. This might be useful for matrices and vectors, but then I would rather wrap them in a struct anyway.

yxhuvud• 13 years ago

[I'm away from a C compiler and can't test]:

What happen if you do

void bar(int fooArray[static 0]) {} ?

Is NULL allowed?

ehamberg3• 13 years ago

    test.c:3:30: warning: 'static' has no effect on zero-length arrays [-Warray-bounds]

quasive2• 13 years ago

According to section 6.7.5.2p1 of C99: “If the expression is a constant expression, it shall have a value greater than zero.”

The “expression” here refers to an expression in between [] in an array declaration; so the declaration of size 0 is a constraint violation and requires a diagnostic. You can get gcc and clang to issue a relevant diagnostic with “-std=c99 -pedantic”.

tptacek• 13 years ago

I am convinced there is some kind of long-term drinking game going on in the C standards committee to see how many different uses they can come up with for the word "static".

bunderbunder4• 13 years ago

With bonus points for uses that have absolutely nothing to do with the word's common meaning.

Evbn• 13 years ago

Hooray for forward compatibility. "static" means "Semantic Token Always Taken In Context."

crest• 13 years ago

Today i learned what s.t.a.t.i.c. stands for.

matthavener2• 13 years ago

They don't really have a choice, do they? If you want to add features you can either: 1) make a new reserve word, possibly breaking existing code 2) reuse a reserve word in a new context.

bunderbunder4• 13 years ago

One better choice that comes to mind:

  void bar(int myArray[10+]);

mikeash3• 13 years ago

C reserves part of the namespace for the language or implementation, so they have a third way, which they've used for e.g. boolean types in C99. Make a new reserved word in the reserved namespace (either starting with __ or just _ followed by a capital letter) and then add a standard header to #define or typedef the unfriendly reserved word to something nicer for code that wants it.

evincarofautumn• 13 years ago

Or you can add context-sensitive keywords, which are keywords only where it’s syntactically valid and identifiers elsewhere. Those two contexts are almost always mutually exclusive, and it’s obvious which one you’re in. ActionScript 3, though absolutely not a good example of language design in general, has a good example of this. You can say:

    public function get foo():int { return 5; }

But you can also say:

    var get:int = foo;

rwmj• 13 years ago

Larry Wall (author of Perl) used this as an argument for "sigils", that is, putting $/@/% in front of every variable.

http://stackoverflow.com/questions/1091634/why-do-perl-varia...

(I merely state this as fact and offer no judgement!)

unimpressive5• 13 years ago

"Nobody really knows what the Bourne shell's grammar is. Even examination of the source code is little help."

— Tom Duff

Not exactly the same situation, considering that compilers work.

cmccabe4• 13 years ago

It's not at all the same situation for C. C's grammar is very-well defined and not at all hard to parse.

C++, on the other hand, has a horribly complex grammar. It would be unfair to say that "nobody really knows what it is," given that it has been standardized. But I think you will find that many tweaks to your code are needed when going between different C++ compilers.

I think what a lot of commenters in this thread are missing is that while the concept of a highly context-sensitive grammar seems simple, the reality is not. And having such a grammar makes it virtually impossible to have good tools.

Before some pedant reminds me that C's grammar is also context-sensitive: yes, I know. But you can parse C with lexx and yacc anyway, whereas you have no hope of doing this in C++.

gatherknwldg• 13 years ago

That is a comment on the style of C that Bourne used in his shell implementation. He used the pre-processor to e.g. name { BEGIN, } END and do other Algol-isms.

Duff would apparently rather read C that was written in C.

chubot• 13 years ago

(off topic) I'm sure that was true at some point, but the comment is out of date now. To my surprise, if you download the current bash source code from [1], it actually has a yacc grammar -- see parse.y. It's 6000 lines, but it would be less intelligible without yacc I'm sure.

Honestly, it might be Stockholm syndrome, but I don't find bash hard to parse at all. The only real problem I see is that people get in trouble when they try to nest quoting styles. But there's basically never any reason to do that. User-defined functions basically eliminate this (may not be POSIX compliant, but supported in all shells I know of),

I factor all my shell scripts into 2 to 10 line functions and they are super easy to maintain and are 5-10x shorter than any alternative.

[1] http://tiswww.case.edu/php/chet/bash/bashtop.html

Nav_Panel2• 13 years ago

Doesn't seem to work for me using GCC 4.7.2.

flags: -g -Wall -Wextra -std=c99 -pedantic

The following code compiles and runs (for me at least) with no errors. Tried with both stack and heap allocated arrays of various sizes.

    #include <stdlib.h>
    
    void foo(int array[static 10]) {
      (void) array; // suppress unused var compiler warning
      return;
    }
    
    int main () {
      int *x = calloc(10, sizeof(int));
      int *y = calloc(9, sizeof(int));
      int *z = calloc(11, sizeof(int));
      foo(x);
      foo(y);
      foo(z);
      foo(NULL);
      int a[9];
      int b[4];
      int c[11];
      foo(a);
      foo(b);
      foo(c);
      return 0;
    }

ambrop72• 13 years ago

I've tried this, and gcc indeed doesn't produce warnings even with -Wall -Wextra. Clang does however without needing any flags.

qznc• 13 years ago

My clang (3.0-6ubuntu3) does not.

niggler4• 13 years ago

Not in front of a computer, but have you tried -std=gnu99

DiabloD3• 13 years ago

Thats a bad way of writing code, to be honest. On projects I run, code has to be warning free with -Wall -Wextra -pedantic -std=c99

Nav_Panel2• 13 years ago

Just tried it now. Still compiles/runs without errors.

jrajav• 13 years ago

I can confirm. Perhaps this is a bug? As per the C99 standard [Clause 6.7.5.3: Function Declarators, point 7]:

A declaration of a parameter as "array of type" shall be adjusted to "qualified pointer to type", where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. 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.

Since that's a 'shall' declaration, shouldn't it at least throw out a warning?

quasive2• 13 years ago

This "shall" is not listed under "Constraints", so violation of it is undefined behavior and does not require a diagnostic. See 4 (Conformance): If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined.

This is an area where a compiler can (sometimes) see violations, though, so I think gcc should diagnose when possible, in the same vein as format specifier mismatches in printf().

onedognight• 13 years ago

> The information provided by static in parameter array declarators is not used for optimization.

This is not a reason to avoid the construct, but as yet gcc[1] doesn't optimize it either.

[1] http://gcc.gnu.org/c99status.html

adamnemecek• 13 years ago

Can someone recommend a resource that talks about some interesting C stuff similar to this? I've looked at "Expert C Programming: Deep C Secrets" but found it a bit outdated. And the C standard is a bit dry :-).

sramsay• 13 years ago

You might look at 21st Century C: C Tips from the New School by Ben Klemens. It's very new (November 2012), and has some really nice stuff in it.

It's getting mixed reviews, but I really found it useful (even if I, like others, disagree with some of his tips). It's particularly good at sorting out what you can do in C99 and C11.

[edit: He has a really useful section on sorting out the different meanings of "static" in C, though I don't recall this being one of them.]

silentbicycle• 13 years ago

The International Obfuscated C Code Contest (http://ioccc.org/) has some real gems.

Compiling another language to C is good way to learn a lot about C's nooks and crannies.

You could also look at C coding standards such as the MISRA guidelines. While many things they complain about should be obvious, there will inevitably be some really obscure things they urge you not to try.

apaprocki• 13 years ago

Using 'static' in this way compiles with both Oracle Studio 12 and IBM xlc 11, but neither exhibit the behavior that gcc is shown to have in the article. Passing in both NULL as well as an array of shorter length work just fine with no warning/error from the compiler.

So, YMMV.

cedricd• 13 years ago

Interesting, but the one comment I haven't seen yet on this thread is 'Why is this useful enough to be a compiler feature?'. I think this is especially relevant with a relatively slim language like C.

In the rare cases you need to do this sort of check why not just write a simple sizeof test?

mauvehaus• 13 years ago

The compiler doesn't pass any size information when you pass an array into a function. The function just gets a pointer. If you take the sizeof the array, you'll get the size of a pointer on your system:

[eric@rangely foo]$ cat foo.c

    #include <stdio.h>

    int test (int arr[10])
    {
        printf ("%lu\n", sizeof (arr));
        return 0;
    }

    int main (int argc, char *argv[])
    {
        int arr[5];
        test (arr);
        return 0;
    }

[eric@rangely foo]$ gcc foo.c -Wall -o foo && ./foo

(EDIT: fixed formatting)

corysama• 13 years ago

Wouldn't you need to put your sizeof test outside of every call to your function? Inside the function it would only know the declared parameter's type, so it would have no idea what sized array you actually passed.

kelnos2• 13 years ago

As another poster said, the compiler can't know inside the function body the size of the array passed if you just use sizeof.

More to a style/safety point, if I ever see a function that expects an array and doesn't also take the size of that array as another parameter, that's a bug waiting to happen.

Especially in this case since this feature seems to only throw a warning on recent versions of clang, and more or less nothing else.

PySlice2• 13 years ago

Why do many features added to C after the first standard have to be quirky and slightly incompatible (with C++, with existing implementations, etc.) like this?

Other examples are inline (different from C++, makes use of weird combinations with static and extern) and tgmath (compiler magic inaccessible to user-defined functions until C11).

They also seem to __barely__ improve the language without ever being "cool" or "interesting".

At least C++ has some standard data structures...

PS: Even Python has binary literals, while they were deemed "not useful enough" for C.

huhsamovar• 13 years ago

This is legitimately awesome, and allows for cleaner code. Nice post!

galaktor• 13 years ago

a bit off-topic: Golang has a similar feature built into it's type system [1]

"The size of an array is part of its type. The types [10]int and [20]int are distinct."

[1] http://golang.org/doc/effective_go.html#arrays

FlawedDesign• 13 years ago

Live test case: http://liveworkspace.org/code/2uk7hc$18

A nice, little known C feature: Static array indices in parameter declarations

Related Stories