Is it good practice to have the same function names in multiple header files?

Question

I'm writing a userland in C (be it minimal at the moment) and I'm making it like BusyBox where you can run a command by invoking a symlink with its name. I've got a "main" C file which includes all the other files inside it (the other files are header files) and then runs their code if the symlink name matches. I was wondering whether it is deemed OK to have functions with the same name across different header files?

For example, if I had thing1.h :

void help(void)
{
    // Print help text for thing1
}

int thing1(int argc, char *argv[])
{
    if (something)
        help();
}

And thing2.h :

void help(void)
{
    // Print help text for thing2
}

int thing2(int argc, char *argv[])
{
    if (something)
        help();
}

And everything.c :

#include "thing1.h"
#include "thing2.h"

int main(int argc, char *argv[])
{
    if (something)
        thing1(argc, argv);
    else
        thing2(argc, argv);
}

Would it be better to rename those help functions to thing1_help and thing2_help respectively, or is it OK to leave them as they are?

Answer 1

First, please understand more how the C preprocessor works and read also the documentation of cpp .

Notice that preprocessing is a purely textual operation. So you could avoid having any header files and #include directives, eg by copy-and-pasting things. That would be a bad idea.

So header files are mostly a conventional thing (however, the C99 standard does mandate some standard headers, like <stdlib.h> or <stdio.h> ; and POSIX specifications also mandates several headers). Common practice includes:

• wrapping the header file contents with an include guard (to disable multiple inclusion)
• putting only declaration , not definition of (often "global") functions, types, variables in header files.
• putting the definition of static inline functions in header files.

Actually, standard header inclusion (eg #include <stdlib.h> ) could even in principle be implemented without any stdlib.h textual file : the compiler implementation could for instance query a database to process #include <stdlib.h> directive, but I know no compiler doing that.

Some people (me included) are putting #include directives (notably for standard C99 or Posix headers) inside their header files. Others are documenting the list of headers to be included before their own header files.

Look at the preprocessed form of your code (which is what most of the compiler care about, since the preprocessor is the first phase of the compiler). You could obtain the preprocessed form of everything.c using GCC with

 gcc -C -E everything.c > everything.i

Then look inside everything.i with an editor or a pager.

In practice, I would suggest to make -if it is really short- your thing2 a static inline function, then to have a single (not several) header:

// file thing.h
#ifndef THING_INCLUDED_
// declarations
void help(void);
int thing1(int argc, char *argv[]);
// definition:
static inline void thing2(int argc, char**argv) {
   if (something_with(argc, argv)) 
      help();
} 
#endif /*THING_INCLUDED_*/

then put the definitions of help and of thing1 in eg your everything.c and add there an #include "thing.h" after the others #include directives.

Answer 2

Both help functions should be the respective c files then it wouldn't matter that there's a name clash as they are private to the scope of that compilation unit.

In general keep code in c files and only declarations in h files.