> "extern" is part of the linker stuff, not compiler.

IMHO, it is also a compiler's stuff because the compiler needs to process it and put the corresponding object code that the linker can process later.

> Don't know where you got that "u. truth"

I concluded that myself because, although there is a difference between declaring a global variable with or without extern storage class specifier, my textbook said that there is no difference between declaring a function prototype with or without one. To quote a paragraph on page 164 of Deitel & Deitel's C How to Program, 3rd edition:

There are two types of identifiers with static storage duration: external identifiers (such as global variables and function names) and local variables declared with the storage class specifier static. Global variables and function names are of storage class extern by default.

Moreover, I also want to demonstrate that there is no difference between applying or not applying storage class specifier extern to a function prototype. Below I have two C source code files: one has a function prototype prefixed with extern and the other one does not have one. As it can be seen, there is no difference at all in the generated assembly code files (cc -o assembly_code.S -S source_code.c). To conclude, there is no difference between applying or not applying extern to a function prototype.

extern int eus_var(int);

main()
{
        eus_var(0xBEEF);

        return 0;
}

        .file   "extern_var.c"
        .text
.globl main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
        subl    $12, %esp
        pushl   $48879
        call    eus_var
        addl    $16, %esp
        movl    $0, %eax
        leave
        ret
        .size   main, .-main
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.3.6"

int eus_var(int);

main()
{
        eus_var(0xBEEF);

        return 0;
}

        .file   "non_extern_var.c"
        .text
.globl main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
        subl    $12, %esp
        pushl   $48879
        call    eus_var
        addl    $16, %esp
        movl    $0, %eax
        leave
        ret
        .size   main, .-main
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.3.6"

> for different objects (compilation units) extern is the only way to have function implementation available.

I would be happy if you can give a concrete example of such a case.

Hi Ho!

That way, your implementation gets its globals allocated and initialized, and not declared "extern", and users of the header get only extern declarations without the initialization,

If it is about variables, yes, you are right.
But, if it is about function prototypes, declaring only extern or not does not matter because in either case the function prototypes are treated as extern by default.

but there is only _one_ declartion used by both -- so there are not two sets of declarations to keep in sync.

Yes, this is valid only if you are talking about variables.
But, this is invalid if you are talking about functions. You still have to define the functions besides having their declarations in the header files. So, in this case, you have to retype the functions prototypes when you are defining the functions (i.e., there are two sets of "declarations" to keep in sync.)

Deriving from the given example, the code for the definition of some_var and some_func will be like the following one:

#define DECLARE_GLOBALS
#include "whatever.h"

int some_func() // Now you have to keep this in sync with the one in "whatever.h"
{
  ...
}

The aformentioned trick should not be used because the effort is not worth the benefit. The argument that you do not have to keep two sets of declarations in sync is inadequate because, whether or not this trick is employed, when you change the names of the variables or the functions, you still have to fix them everywhere.

The trick also limits the flexibility of the definition of each of the global variables. Specifically, the variables can only be defined in one translation unit. This may cause low-cohesion because not all global variables should be defined in a single translation unit. For example, my_robot.h defines global variables such as steps_per_second and eye_blinks_per_second. Naturally, steps_per_second should be defined in legs_controller.c, while eye_blinks_per_second should be defined in eyes_controller.c. In contrast, using the suggested trick, those variables must be defined in, for example, brain.c. However, brain.c should not define them. Instead, it should only initialize them according to the default values that the programmers can specify in an external file, for example, robot.conf or in a flash ROM.

The trick also clutters a translation unit because of multiple usages of #define DECLARE_GLOBALS when the translation unit needs to define global variables from more than one header file. For example,

#include "a.h"
#include "b.h"
#define DECLARE_GLOBALS
#include "c.h"
#include "d.h"
#define DECLARE_GLOBALS
#include "e.h"
#define DECLARE_GLOBALS
#include "f.h"

This is very likely to hamper the speed of a new maintainer of the code in understanding the code because the maintainer will lose concentration once #define DECLARE_GLOBALS is spotted.

Finally, the trick requires double effort to check which global variables are declared in a certain translation unit because a lookup to the related header files are needed. Futhermore, the trick makes the types of the global variables opaque from the programmer. This significantly reduces the readability of the translation unit. It is far cleaner and more transparent if the trick is not employed like what the following code illustrates:

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"
#include "e.h"
#include "f.h"

int c_global_var = 99;
double e_global_var = 7.77;
struct something **f_global_var = NULL;

In short, I wonder how you perceive this trick as a neat one that can benefit you in any way.