invalid application of 'sizeof' to incomplete type 'struct array[]'

Question

I am trying to organize my project by splitting commands up into separate files for easier maintenance. The issue I am having is trying to iterate over the array of commands defined at compile time. I have created a dumbed down example that reproduces the error I am getting.

.
├── CMakeLists.txt
├── commands
│   ├── CMakeLists.txt
│   ├── command.c
│   ├── command.h
│   ├── help_command.c
│   └── help_command.h
└── main.c

./CMakeLists.txt

PROJECT(COMMAND_EXAMPLE)

SET(SRCS main.c)
ADD_SUBDIRECTORY(commands)

ADD_EXECUTABLE(test ${SRCS})

commands/CMakeLists.txt

SET(SRCS ${SRCS} command.c help_command.c)

commands/command.h

#ifndef COMMAND_H
#define COMMAND_H

struct command {
    char* name;
    int   (*init)(int argc, char** argv);
    int   (*exec)(void);
};

extern struct command command_table[];

#endif

commands/command.c

#include "command.h"
#include "help_command.h"

struct command command_table[] = {
    {"help", help_init, help_exec},
};

commands/help_command.h

#ifndef HELP_COMMAND_H
#define HELP_COMMAND_H

int help_command_init(int argc, char** argv);
int help_command_exec(void);

#endif

commands/help_command.c

#include "help_command.h"

int help_command_init(int argc, char** argv)
{
    return 0;
}

int help_command_exec(void)
{
    return 0;
}

./main.c

#include <stdio.h>
#include "commands/command.h"

int main(int argc, char** argv)
{
    printf("num of commands: %d\n", sizeof(command_table) / sizeof(command_table[0]));
    return 0;
}

If you run this

mkdir build && cd build && cmake .. && make

the following error occurs

path/to/main.c:6:40: error: invalid application of 'sizeof' to incomplete type 'struct command[]'

So, how do I iterate over command_table if I can't even determine the number of commands in the array?

I realize there are other posts out there with this same error, but I've spent a while now trying to figure out why this doesn't work and continue to fail:

• invalid-application-of-sizeof-to-incomplete-type-with-a-struct
• invalid-application-of-sizeof-to-incomplete-type-int-when-accessing-intege

Solution 1

For your sizeof(command_table) to work, it needs to see this:

static struct command command_table[] = {
    {"help", help_init, help_exec},
};

But it only sees this:

extern struct command command_table[];

Seeing that sizeof() can never figure out how many elements are actually in there.

Btw, there's another problem. static makes the array invisible in all other modules. You have to remove it or workaround it.

Your options (after removing static) are:

1. hard-coding the number of elements, e.g.

   extern struct command command_table[3];

2. defining an extra variable to hold the number of elements:

commands/command.c

#include "command.h"
#include "help_command.h"

struct command command_table[] = {
    {"help", help_init, help_exec},
};

size_t command_count = sizeof(command_table)/sizeof(command_table[0]);

commands/command.h

...
extern struct command command_table[];
extern size_t command_count;
...

And then you just use command_count.

Solution 2

Explicit the number of elements of your array in commands/command.h:

extern struct command command_table[3];

Comments

[Rich]

Thanks for the tip, explicitly pointing out what the compiler sees. I had the same problem and even after (or because of?) staring at my code endlessly I just didn't spot that obvious trap.

[weefwefwqg3]

Is there any other way around (e.g. using pointers?) to calculate the size of the array without adding command_count into command.h and command.c. In other words, in my case, I have no privilege to edit command.c and command.h.

[Alexey Frunze]

@匿名柴棍 There's no reflection/introspection in C, so you can't just somehow query the description of a type or object. You must know it. However, some non-standard hacks may be possible. E.g. you may be able to extract the symbol/debug info from the object file into which command.c is compiled and then generate an additional include file with the count of the array elements. IMO, it's more practical to just get the needed permission.