yemista wrote:ok i will do it your way. keep in mind my os is purely for my own knowledge and enjoyment, and i never plan to port it, but im guessing there are other reasons i am not seeing to do it this way.
The most important reason is that this is the way it is done in the programming language "C". There is a standard way to do it, i.e. no reason to go through an ASM hack to do it a different way. Not only can you rely on other people's work to get it done, your code will also be better readable for the lack of a custom construct.
(Of course, since you are apparently unfamiliar with the standard construct, this doesn't help
you much. On the other hand, you
do now know what the standard way is, i.e. you have learned something that will help you outside of your OS project, too.)
here is my new code:
Not having done much C coding so far, have you? The idea is to put the source into the header "stdarg.h", wrapped in an include guard, and include that. Someone who already used <stdarg.h> before should have gotten the idea, which I thought was obvious from the comment under my source snippet. (I didn't want to press my way of doing include guards on you, or I would have pasted the complete header.)
now I am getting the following error:
lib/stdio.c: In function ‘kprintf’:
lib/stdio.c:35: warning: implicit declaration of function ‘var_arg’
That's pretty obvious, isn't it? The compiler even tells you the line of the error. One good look at what you wrote there, compared with what you wrote when you defined the macro va_arg (hint, hint) should have solved that.
Also, I understand how the macros work, all except for PDCLIB_va_round. thats still black magic to me.
Different types have different alignment rules. The macro does some math to get the alignment right for types that have other alignment rules than void *. (The double type would be a good example here.)
I also dont understand what the code "*(type*)" does in va_arg. Is that just a double pointer? Or is it making a new pointer of type type and deferencing it?
(type *) is a cast of the expression to the right to "pointer to type".
The * in front of that dereferences the pointer.
I strongly suggest you try yourself at some non-trivial
user-space application first. You need to be
proficient in your language of choice before tackling kernel-space programming. If the language gives you such trouble already, kernel space is
not the environment to practice in, as it is a definitely hostile environment to be in. The usual tools (e.g. debuggers) fail you, you don't get much error output other than a triple-fault / reboot, and people in relevant forums expect you to be a competent developer in your own right...
In user-space, there is much more patience applied to newbie questions...
