including header file

[slacker]

how can including a header file whose functions are never called by the kernel cause the kernel to malfunction?

[slacker]

heres is that header file: com.h

Code: Select all

#ifndef __COM_H
#define __COM_H

char COMMAND[100];

int getLEN()
{
 int i=0;
 while(COMMAND[i]!=0)
 i++;
 return i;
}

void resetCOM()
{
 for(int i=0;i<getLEN();i++)
 COMMAND[i]=0;
}

void addCHAR(char newCHAR)
{
 int len=getLEN();
 COMMAND[0]=newCHAR;
}

void remCHAR()
{
 int len=getLEN();
 COMMAND[len-1]=0;
}

#endif

[Whatever5k]

BEEP! Never place functions in header files (except static inline functions). Again: functions belong to real code (.c). Headers are for prototypes, definitions and maybe inline functions.

edit:
What type of error do you get? Where does your OS "hang"? Does the compiler issue an error/warning? Some more informations would be great.

[distantvoices]

In this include file, I miss the function declarations.

that slacker shall keep the function definitions in an extra file, say com.c, stands on an other sheet of paper

[slacker]

thanks for the header tips but my problem was the floppy disk i was using...i guess it went bad cause i tried another disk at it worked fine.

[Pype.Clicker]

how can including a header file whose functions are never called by the kernel cause the kernel to malfunction?

for the nth time ...

• the function included may move your _start symbol somewhere else. If your startup sequence isn't flexible enough, the bootloader might not found the _start anymore and run random function instead. Use objdump -d to see if your kernel matches your expectations
• adding bytes may hide/expose some misinitialized pointers bugs: without the code the misinitialized pointer pointed to unused ram and everything seemed to work fine, with the extra code, it now points somewhere in an important area that will get damaged
• your bootloader may need an update to load a larger kernel (this advocates for the use of a generic bootloader like GRUB )

[pini]

Doesn't matter where functions are located !
You can write functions in header file without problems, because preprocessing will only replace the #include statement with the functions themselves, just as if you wrote them directly in the calling file.
Check these :
Prototypes ?
Is the kernel entry point still reachable, if you include com.h before it ?
Is the kernel fully loaded (including a file causes the kernel to get bigger) ?
Try including it at the end of the kernel code.

And please, stop being so psycho-rigid with this include stuff.
*.h & *.c don't have so much differences !

[Pype.Clicker]

And please, stop being so psycho-rigid with this include stuff. *.h & *.c don't have so much differences !

For sure: both are plain text files ...
*but* .c files are usually read ONCE in the compile process and .h are supposed to be included by MANY .c, therefore, their content is read many times and if it has code in it, your code will be duplicated in the final object file ...

This is not psycho-rigidism or whatever. This is a rule.
Nothing prevents you from calling your files .x and .Y if you really want to ...

The C designer, Kernighan & Ritchie have introduced .Code and .Header files ... put header stuff in header files and code in code files. period. If you don't, expect regretting your decision soon or late ...

and, as we are in "psycho-rigidism" ... tabs should be 3 spaces and the "{" sign comes on the same line as for( ... ) and if (...), not the next one ... enforcing *this* would be stubbornness. C/H rule isn't.

[Tim]

pini, we're being psycho-rigid for a reason!

You're right that there are few differences between .H and .C files. If you #include a header file with function defintions, those definitions get pasted directly into the .C file. So you can easily break your kernel by putting function definitions into a header file then including that file before your main() function. The functions in the .H go before main() in the binary and your kernel breaks.

You must not put anything other than function declarations, extern variables, static functions/variables and typedefs/structs/#defines in a header file. If you actually define anything (such as a variable without extern or static, or a non-static function body) you will enter a world of pain, either from the linker or the loader.

It sounds like some of the people reading this board could do with revising their knowledge of the C programming language.

[pini]

and, as we are in "psycho-rigidism" ... tabs should be 3 spaces and the "{" sign comes on the same line as for( ... ) and if (...), not the next one ... enforcing *this* would be stubbornness. C/H rule isn't.

Yeah, this is *really* psycho-rigidism !
I can easily understand why some people still differentiate their code from their header files, but with correctly dispatched #ifdef & #ifndef statements, a multiple included header file can contain code, without expecting to regret it "sooner or later".

[slacker]

THIS IS WHY IT DIDNT WORK: when i included the file the kernel size was greater than 8 sectors. when it wasnt included the kernel was 7 sectors. sector 8 was bad.

[Tim]

pini: no amount of #ifdef statements will let you put code into a header file successfully. The rule is: if there is more than one public symbol (function or variable) with the same name, the linker will give you an error. If two .C files include the same .H file, and that .H file has function with bodies (i.e. function definitions), it will be as if you had written that function twice. The linker doesn't know what came from a header and what came from a source file, so it fails anyway.

[Pype.Clicker]

consider the following example : kernel.o is built by linking core.o, memman.o and disk.o

core.o is ((include types.h)(include video.h) core.c )
disk.o is ((include types.h)(include disk.h)(include video.h) disk.c)

Now, if video.h contains the code for printf itself (rather than just the prototype), the code of printf will be replicated in core.o and in disk.o

and no #ifdef can help you as core.o and disk.o have been compiled separately (believe me, one day you'll have to compile things separately ), thus the preprocessor completely ignores what is in core.c while producing disk.o

result is:
disk.o = [ <printf> <content from disk.c> ]
core.o = [ <printf> <content from core.c> ]
ld : in kernel.o: printf defined multiple time

So the solution K&R envisionned was to put use .C files as black box holding code and to describe the interface to those black boxes in the .h file ...

thus
disk.c : [ [ interface for core ] [ interface for video ] [ interface for disk ] implementation for disk ] --> disk.o
core.c : [ [ interface for core ] [ interface for vide ] implementation for core ] --> core.o
video.c [ [ interface for core] [ interface for video ] implementation for video ] --> video.o

[distantvoices]

I 've learned this issue the quick way: 've put some functions in a header (actually, i 've learned this from fritzos *gg*) and then, at the first Time I have had two modules including this header to link, it turned out to be crap. So I have redesigned the whole thing, put the code in an extra file, the declarations and #defines in an other file, and then I ve created a multipurpose header to be included by every other module. This is now my input/output module, say the console driver.

@pini&slacker: It is not only a question of ... easing life, but also a question of clean design. you can really ease your life by splitting DECLARATON and DEFINITION. When you want to call a function and don't know the parameter list, it it is easier to open the header file and search for the declaration of the function then to scroll around in one single file - afterwards you have to search you last position. Clean design: You put functions needed by many modules in some standard headers. these headers you include in every module that needs them. You have the modules containing those functions compiled ONCE, and pass References to the functions to other modules.

I know i know by this time of the day it is expected too much to activate some cells in the brain *gg* go 'n' have some coffee.

med v?nlig h?lsning

[Tim]

More generally, this is about interfaces and implementations. The source files provide the implementations: how things are done. The header files contain the interfaces: how to use those things. Users of the implementation (callers of the functions) don't need to know how they work beyond what the interface looks like (what the parameters, return value and side effects are).