Possible to compile any .c file in isolation (that is, without a main?)

Question

I currently have a "library-like" .c file (that'll be shown below). I have 2 questions about it:

1. If I want to see if it compiles well for itself, how can I do it? If I try to gcc it, it will always give a "no main" error, which makes sense, but raises the problem of knowing if a given .c file will compile well or not in "isolation". Can I safely conclude that if the only error raised by the compiler is the "no main" one, my file is fine? An example of where compiling .c files in isolation could be nice would be to determine which includes are in excess, in here.

2. Is there a point in a simple file like this to define a header with its method / struct declarations and then have such tiny .c file with the code implementation in it?

    #ifndef SEMAFOROS #define SEMAFOROS #include <signal.h> #include <sys/mman.h> #include <sys/stat.h> #include <fcntl.h> #include <semaphore.h> typedef struct { sem_t* id; char* nome; } Semaforo; inline void lock(Semaforo* semaforo) { sem_wait(semaforo->id); } inline void unlock(Semaforo* semaforo) { sem_post(semaforo->id); } Semaforo* criarSemaforo(char* nome) { Semaforo* semaforo = (Semaforo*)malloc(sizeof(Semaforo)); semaforo->id = sem_open(nome, O_CREAT, 0xFFFFFFF, 1); semaforo->nome = nome; } void destruirSemaforo(Semaforo* semaforo) { sem_close(semaforo->id); sem_unlink(semaforo->nome); 
    free(semaforo); 
   \n\n} \n\n\n#endif \n

Thanks

Answer 1

To compile it without linking (doesn't require a main entry point):

cc -c file.c -o file.o

Even for a small file that defines routines that will be called from other source files you still want a header file. The header file is how the compiler knows the interface to the routines before the linker ties it all together. If you don't have declarations for functions that are external then the compiler has to make assumptions (usually wrong) about the data types of the parameters. You can declare the functions in every source file where they are used, but the point of header files is so that you just do it once in the header file.

Answer 2

The -c option to gcc seems to be what you are missing, which compiles one .c file to a .o file.

The answer to your second question is 'sure'. It's a good habit not to be typing externs into all the .c files that want to use some shared function or another. Every little .h helps.

Answer 3

For the second question, I'd like to know why!

To answer point 2, keeping declarations in a header file helps you avoid situations like the following.

You decide that you need to keep track of your chickens in file.c :

int number_of_chickens;

In file2.c , you decide that it would be a great idea to represent the number of chickens as a double instead of an int, but you forget to update file.c :

extern double number_of_chickens;
double count_chickens() {
    return number_of_chickens;
}

void add_to_chickens(double how_many) {
    number_of_chickens += how_many;
}

This will compile just fine. The linker will treat number_of_chickens as a name referencing a 4 bit int in file.c , and an 8 bit double in file2.c .

If you call the count_chickens function, it will return garbage (the high 32 bits of the double will be filled in with the contents of int number_of_chickens , the low 32 bits will be undefined - whatever comes after number_of_chickens in memory).

Even worse, when you call add_to_chickens(1) in file2.c , you will write 8 bytes to a 4 byte storage location, surely causing havoc, but not necessarily causing a runtime error (at least, not right away).

If you keep your external declaration in a common header file, you get a compile time error immediately. If you don't, you instead get an unexplained instability 3 months after you ship.