Daft Question i think
Basically i have two .c files and a .h file
One of the .c files contains a function:
if the declaration for this function is at the top of the c file it is in it builds perfectly, however second i move it into the header file i get errors. The reason i need the declaration in the header file is because it is called from the other .c file.
TransferMessage(int Port, struct Device *example)
example[Node].Address = ...
>>> however second i move it into the header file i get errors
What do you mean? :)
Remember that it must be visible to parts of code that need this function.
Also you said "error" , but i can not locate your description for it...
You may be mixing terms. Declaration is simply a description of the function, i.e. a prototype: the return type, name of the function, and all it's parameters. The definition includes the implementation or function body. More info here: What's the difference between declaring and defining in C and C++ - Cprogramming.com.
If you're moving the definition into the header file that's wrong*. Keep variable and function definitions out of .h files. .h files just describe the name and type of a thing, they shouldn't reserve storage space for variables, or have actual code in them.
All you need in the .h file is a function prototype, or declaration. Something like this:
That extern keyword is to notify the linker** that the definition of the function will be in some other .c file. Thus, if the definition is in foo.c, and you #include this header in bar.c, the linker will see this extern function called TransferMessage. It wont worry about not being able to find it right away, in the same file. It will know that function exists externally to bar.c, in some other file.
extern TransferMessage(int Port, struct Device *example);
That semicolon is there just to tell the compiler there is no function body (definition) to follow, just a declaration.
One more note, all your header files should have include guards (link). They keep the compiler from complaining about multiple declarations, by preventing the same .h file from being included multiple times in the same translation unit. A translation unit is a technical term that is basically a .c file.
* It is okay to have the definition in a header file in some rare circumstances, most notably if you "inline" the function. That is a trick to help make your code faster, but it is something you should not bother with 99.9% (or more) of the time.
** The linker was traditionally a separate component from the compiler proper. It is still a separate entity in many implementations, but now the compiler usually handles both stages seamlessly. The compiler proper would turn a .c file into an object file (often suffixed .o), which contained (roughly) the machine code for the .c file. The linker would combine that object file with any other object files you specify, as well as libraries and "startup" and "cleanup" code. There is often code that runs before and after your main function, that sets up and cleans up behind the scenes stuff that you usually don't need to worry about.
Maybe it is because of struct Device? Also you need a return type to avoid "implicit declaration" in C90 mode and errors in C99 mode.
Here is a "cookbook" approach:
Header file transfermessage.h:
Implementation file transfermessage.c:
int TransferMessage(int Port, struct Device *example);
Main program main.c:
int TransferMessage(int Port, struct Device *example)
// struct_device.h should provide some function which gives
// back a valid initial struct Device object
struct Device d = device_init();
int retval = TransferMessage(1234, &d);
printf("TransferMessage returned code %d\n", retval);