How a standard library differ from user defined header file (.h) and its implementation file (.c) in C?

Question

How a standard library like libc.a (static library) which is included using #include in our main.c differ from user defined header file (cube.h) inc

Answer 1

A programming language is not the same as its implementation.

A programming language is a specification (written on paper; you should read n1570, which practically is the C11 standard), it is not a software. The C standard specifies a C standard library and defines the headers to be #include-d.

^{(you could run your C program with a bunch of human slaves and without any computers; that would be very unethical; you could also use some interpreter like Ch and avoid any compiler or object or executable files)}

How a standard library like libc.a (static library) which is included using #include ... differs from a user file cube.c

The above sentence is utterly wrong (and makes no sense). libc.a does not #include -or is not included by- the header (i.e. file /usr/include/stdio.h and other internal headers e.g. /usr/include/bits/stdio2.h). That inclusion happens when you compile your main.c or cube.c.

In principle, might not be any file on your computer (e.g. #include could trigger some magic in your compiler). In practice, the compiler is parsing /usr/include/stdio.h (and other included files) when you #include .

Some standard headers (notably , , , ....) are specified by the standard but are implemented with the help of special builtins or attributes (that is "magic" things) of the GCC compiler.

The C standard knows about translation units.

Your GCC compiler processes source files (grossly speaking, implementing translation units) and starts with a preprocessing phase (processing #include and other directives and expanding macros). And gcc runs not only the compiler proper (some cc1) but also the assembler as and the linker ld (read Levine's Linkers and Loaders book for more).

For good reasons, your header file cube.h should practically start with include guards. In your simplistic example they are probably useless (but you should get that habit).

You practically should almost always use gcc -Wall -Wextra -g (to get all warnings and debug info). Read the chapter about Invoking GCC.

You may pass also -v to gcc to understand what programs (e.g. cc1, ld, as) are actually run.

You may pass -H to gcc to understand what source files are included during preprocessing phase. You can also get the preprocessed form of cube.c as the cube.i file obtained with gcc -C -E cube.c > cube.i and later look into that cube.i file with some editor or pager.

You -or gcc- would need (in your example) to compile cube.c (the translation unit given by that file and every header files it is #include-ing) into the cube.o object file (assuming a Linux system). You would also compile main.c into main.o. At last gcc would link cube.o, main.o, some startup files (read about crt0) and the libc.so shared library (implementing the POSIX C standard library specification and a bit more) to produce an executable. Relocatable object files, shared libraries (and static libraries, if you use some) and executables use the ELF file format on Linux.

If you code a C program with several source files (and translation units) you practically should use a build automation tool like GNU make.

If I included include guards in cube.h what would happen when I include cube.h in both main.c and cube.c ?

These should be two different translation units. And you would compile them in several steps. First you compile main.c into main.o using

 gcc -Wall -Wextra -g -c main.c

and the above command is producing a main.o object file (with the help of cc1 and as)

Then you compile (another translation unit) cube.c using

gcc -Wall -Wextra -g -c cube.c

hence obtaining cube.o

^{(notice that adding include guards in your cube.h don't change the fact that it would be read twice, once when compiling cube.c and the other time when compiling main.c)}

At last you link both object files into yourprog executable using

gcc -Wall -Wextra -g cube.o main.o -o yourprog

(I invite you to try all these commands, and also to try them with gcc -v instead of gcc above).

Notice that gcc -Wall -Wextra -g cube.c main.c -o yourprog is running all the steps above (check with gcc -v). You really should write a Makefile to avoid typing all these commands (and just compile using make, or even better make -j to run compilation in parallel).

Finally you can run your executable using ./yourprog (but read about PATH), but you should learn how to use gdb and try gdb ./yourprog.

Where it cube.h will get included?

It will get included at both translation units; once when running gcc -Wall -Wextra -g -c main.c and another time when running gcc -Wall -Wextra -g -c cube.c. Notice that object files (cube.o and main.o) don't contain included headers. Their debug information (in DWARF format) retains that inclusion (e.g. the included path, not the content of the header file).

BTW, look into existing free software projects (and study some of their source code, at least for inspiration). You might look into GNU glibc or musl-libc to understand what a C standard library really contains on Linux (it is built above system calls, listed in syscalls(2), provided and implemented by the Linux kernel). For example printf would ultimately sometimes use write(2) but it is buffering (see fflush(3)).

PS. Perhaps you dream of programming languages (like Ocaml, Go, ...) knowing about modules. C is not one.