OSDev.org

Hello, I followed Bran's tutorial, he used extern with functions,
but from what I read and tested, extern is only needed with variables..
Is there some reason he used extern for functions aswell?

Hi,

Technically speaking you can get away without using the extern keyword on functions in C. It is used to denote a function which is used by the current compilation unit but defined elsewhere, and is usually used solely in .c files (as opposed to header files). It makes no difference to the C compiler/linker whether the 'extern' is there or not, as in C (as opposed to C++) all global functions etc have global scope as default, not file scope (use 'static' to override).

It can, however, help the programmer determine easily where the definition of a function (does not) reside.

Cheers,

James

Thanks for the fast reply, dont see how it can "help the programmer determine easily where the definition of a function (does not) reside" since its just a keyword or did i miss something?

So from what i understand, 'extern' is always needed by C++ this is why i see in the header files these lines:

correct?

Hi,
You should know what the extern keyword functions when applied to functions.
When a function is declared without the keyword ,and object code is generated for the source file,the function is mangled,that is an underscore is added at the end.So a function such as:
myfunct()
will become:
_myfunc()
If you look at the nasm code you will see that nasm mangles the c functions when called from within it.So to call our function without the extern keyword in nams we will need to do it this way:
call __myfunc();notice the double underscore
double underscore are usually reserved for compiler specific operations,
so you use extern to unmangle the functions so you can call then like this from nasm:
call _myfunc()

Ok, but main wasn't declared extern and we still "call _main"..

this was another thing i thought about asking, why the built-in functions and in the headers files they use __

Gcc actually adds the leading underscore to the main function and to other functions.
The problem of double leading underscores arise when you use a c++ compiler.
Secondly,you do not need to the extern in C compilers.
In C,all functions are implicitly declared extern

No, No, No!

The prepending of an underscore is not name mangling. Name mangling is only present in C++, and consists of encoding the namespace, template types and parameters of a function to avoid conflicts with overloading (so you end up with, for 'main()', '_Z4mainv'.)

This only affects C++ code, not C code, and uses 'extern "C"', which is completely different to 'extern' (without the "C").



Yes, it's just a keyword, and yes, it does nothing, however if one sees a function prototype with "extern" before it, one can deduce that the definition of that function is not in the current file. It is elsewhere. This may (or may not) save you time.



Built in functions tend to use preceding underscores so as not to pollute the namespace.

Cheers,

James

Gcc actually adds the leading underscore to the main function and to other functions.
The problem of double leading underscores arise when you use a c++ compiler.
Secondly,you do not need to the extern in C compilers.
In C,all functions are implicitly declared extern

No, it doesn't, on most linux distributions. Cygwin's mingw compiler does by default, but it can be disabled (and reenabled) using a runtime switch. (-fno-underscores or something, I don't remember).



This is just complete and utter tripe, you obviously have no clue what you are talking about.

Cheers,

James

Yes sorry for the rubish wrote before.
Too much deconcentration.
Thanks James for the corrections.I was really out of this planet when writing all of that rubish.

Everything you never wanted to know about those underscores ...

In source code (usually C code), single-underscore is reserved for the OS / system libraries and double-underscore is reserved for the compiler implementation.

This is why (on Linux) you get functions like exit(), which is the POSIX-compatible version that runs atexit() functions, and _exit(), which is a raw syscall that immediately and unconditionally terminates the process. fork() handles all the libc locking, while _fork() is the raw syscall that immediately starts a new process (and probably deadlocks the next time you call into libc because the internal libc locks never get released).

And this is why if you peek at the compiler's header files (e.g. stdint.h), you'll find a lot of macros and types with double-underscores. GCC uses __attribute__ (note the double-underscores) as a language extension, MSVC uses __int64 or __int128 for types that don't exist in the C language. The C specification is very particular about what symbols are allowed in the global namespace, so the compiler puts all its configuration in the compiler-reserved namespace so the compiler's symbols don't conflict with your program.

For the addition of a leading underscore ... most old formats (COFF, upon which Microsoft compilers are based, the old Unix a.out format, MacOSX mach-o) prepend an underscore to all symbol names in C files. I believe this was to avoid accidental (and hard-to-debug) name conflicts between C symbols and temporary assembly symbols generated by the compiler. But when ELF was created, the implementors decided the reasons for doing so were no longer relevant (GCC uses a prefix character that C code cannot generate), so they dropped the implied leading underscore to save a few bytes.