Rudimentary, but not obvious! (About .h files)

This is a discussion on Rudimentary, but not obvious! (About .h files) within the C Programming forums, part of the General Programming Boards category; Ok, you can call me early or late, but if all that's supposed to be included in .h files is ...

  1. #1
    Adamant Programmer Axpen's Avatar
    Join Date
    Jun 2003
    Location
    USA
    Posts
    42

    Rudimentary, but not obvious! (About .h files)

    Ok, you can call me early or late, but if all that's supposed to be included in .h files is declarations and the sort, where are the functions??? For example strcat
    string.h(gcc 3x):
    Code:
    char*	strcat (char*, const char*);
    Ok, now that part certainly makes since to me as a declaration, how ever, how does the compiler know what to do with the arguments with nothing but a declaration (if it's defined in a .o or .a file PLEASE tell me which one too, even though I know they're practically undecipherable) anyways I just want to know where the actual functions to these prototypes are at, and how I can study them or make my own "hidden" functions.

    Thanks for all the help!!!
    The Man With 3 Ears::Oh no better get the huskers

    Download Helppc by David Jurgens, It's a FANTASTIC Reference!!!

    In Case I Forget I Have:
    Windows XP
    For My 32-bit Questions:
    Dev C++ (mainly just use its mingw)
    For My 16-bit Questions:
    Borland Turbo C++ 1.01

  2. #2
    SleepWalker tjohnsson's Avatar
    Join Date
    Apr 2004
    Posts
    70
    ... where are the functions??? For example strcat
    linked on a compile time to your app ( .a )
    or used at runtime from ( .so )
    depends you...

    here's more...
    http://users.actcom.co.il/~choo/lupg...libraries.html

  3. #3
    Registered User
    Join Date
    Apr 2004
    Posts
    6
    Quote Originally Posted by Axpen
    Code:
    char*	strcat (char*, const char*);
    Ok, now that part certainly makes since to me as a declaration, how ever, how does the compiler know what to do with the arguments with nothing but a declaration (if it's defined in a .o or .a file PLEASE tell me which one too, even though I know they're practically undecipherable) anyways I just want to know where the actual functions to these prototypes are at, and how I can study them or make my own "hidden" functions.
    Here's a (hopefully) clear and (definitely) long explaination of how it works.

    The first thing you should understand is that it's not the compiler that produces the actual executable from your code, but another program called the linker. Let's try an example.

    Suppose you have a program split into three source files -- we'll call them src1.c, src2.c and src3.c. When you do the following

    gcc src1.c src2.c src3.c

    you are telling gcc (compiler) to make three object files (named src1.o, src2.o and src3.o) out of each C source file and call on the linker (most likely /usr/bin/ld) to actually "bind them together" into an executable called a.out.

    The reason for this is that the three object files don't know about each other. If you define a function foo() in src1.c and call it from src2.c, when the latter is compiled by gcc the compiler has no clue where the heck foo() comes from -- it just knows how many arguments it takes, what their data types are, and what it returns (since you provided it with a declaration of foo() in src2.c). Fortunately, that's everything it needs in order to emit code for a function call.

    This is possible because of something named the C calling convention. In short, the C calling convention is just a formal specification of how two functions interact, knowing a minimum of information about each other (precisely, the bare minimum of information that a function declaration contains). There's a lot to be said about this, but it requires some knowledge of assembly programming.

    So, when the compiler is done (and is about to call the linker), we have one or more object files which call each other's functions, but aren't aware of each other's presence (e.g. src2.o is calling foo() somewhere but it doesn't know what foo()'s address in memory is because it belongs to src1.o). It is the linker's job to make the modules "aware of each other" by gluing them together and replacing function/variable names by their memory addresses in the final executable.

    Now let's see what happens with strcat(). The difference here is that strcat() isn't defined anywhere in your code -- it is part of the C library. But, since it follows the C calling convention, all gcc needs to know in order to compile calls to strcat() is the number and type of the arguments it expects, and the data type it returns -- it only needs strcat()'s declaration.

    When gcc is done with compiling, it will kindly ask ld to link the object file in question to the C library in your system (you don't have to tell it to do so, since all your C programs have to be linked to the C library), so that the resulting a.out is able to load it at run-time, thus making strcat() available to calls.

    There's no point in looking for strcat in libc.so since it's a binary file and not meant to be read by humans. You could, however, read your libc's source code if you really want to check that strcat() is just a "normal" function like any other you could write yourself.

  4. #4
    Helper
    Join Date
    Jun 2004
    Posts
    255
    Quote Originally Posted by doshell
    Here's a (hopefully) clear and (definitely) long explaination of how it works.
    <good stuff snipped>
    The kind of paper that should be abstracted and stuck on a FAQ...
    Emmanuel Delahaye

    "C is a sharp tool"

  5. #5
    Adamant Programmer Axpen's Avatar
    Join Date
    Jun 2003
    Location
    USA
    Posts
    42
    Yes, thanks alot, that really helped clear up my confusion
    The Man With 3 Ears::Oh no better get the huskers

    Download Helppc by David Jurgens, It's a FANTASTIC Reference!!!

    In Case I Forget I Have:
    Windows XP
    For My 32-bit Questions:
    Dev C++ (mainly just use its mingw)
    For My 16-bit Questions:
    Borland Turbo C++ 1.01

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. I Need To Know Some Things That I Can Put Into A Batch File
    By TheRealNapster in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 10-20-2003, 08:12 PM
  2. Header Files (.h)
    By Mach_ie in forum C Programming
    Replies: 5
    Last Post: 09-23-2003, 05:30 PM
  3. Cant Make heads or tails of .h files
    By D3T in forum C++ Programming
    Replies: 4
    Last Post: 07-09-2002, 10:03 AM
  4. Class files (.h and .cpp
    By Todd in forum C++ Programming
    Replies: 7
    Last Post: 02-14-2002, 02:07 PM
  5. header .h files
    By Unregistered in forum Windows Programming
    Replies: 4
    Last Post: 09-03-2001, 09:26 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21