error codes.

[edfed]

a friend of mine told me that error codes shall be a negative value.
but the BIOS don't do that, windows don't do that and mostlly, hobby os don't do that.
the carry flag is frequentlly used to handle errors, with a value in eax.
is it prefered to have only eax with a negative value or carry flag?

to test errors in case of negative value, we compare eax with 0, and then, jump to error routine.

Code: Select all

test eax,eax
jl .error

in case of carry flag, just the jc or jnc instructions are needed to jump to error routine.

Code: Select all

jnc error

then, as it is a forum about os construction, i presume this case is still resolved, and i just want to know your opinions, with arguments if possible.

[JamesM]

Error codes are almost always positive. *

Some system functions however, return negative numbers on error, and so in linux and solaris at least, return the inverse of the error code it's just thrown on error. Before this gets back to userland it's usually re-inverted, stored into "errno" and a generic "-1" returned to indicate error.

* This post discusses just normal *nix OSs.

[piranha]

If my function returns, say, a file handle number, then the error codes would be negative.

Other than that, it's usually 1 on success and 0 on failure.

-JL

[Korona]

I'm not sure how I will handle error codes. Since my system calls are just usual call instructions (all threads run in ring0 on a virtual machine) I cannot use a special register to return error codes. (Unless I'll built an extension for my compiler that can handle error codes) I guess I'll have my functions return a tupel that contains both the result and the usual return value or I'll let the kernel interface methods throw exceptions on failure.

EDI: One should also consider a thread-local errno() system call. (Although this might have a negative impact on performance due to the increased number of system calls that have to be done).

[bewing]

If people are coding in assembler, they are usually concerned about efficiency. For efficient code in assembler, you don't want to do a TEST E??, E?? -- so you would generally want to return "error codes" in EFLAGS bits. If you are very careful, you can return up to 3 (maybe even 4!)testable EFLAGS bits, to indicate 3 different types of errors: carry, zero, and sign (and parity). You would also need to tell the programmer which order to test the flags in, because they are mutually exclusive to a degree (unless you use the brute force method to set them). Normally you would use carry, but I think it is OK for every single system function to have a unique error bit pattern. Assembly programmers need to be careful with their code anyway.

Then there needs to be an interface to the higher level languages. The interface converts error bitflags to error numbers -- usually storing them in errno (if you want to follow the POSIX standard). I personally don't like the errno method -- because on return from a call, the first thing you want to do is test for an error, before you even think about testing the "return" value. But with POSIX, the easy thing to do is test the return value, and any error code is somewhat hidden from you. So really, POSIX has it backwards.

Of course, this is all ignoring the entire concept of asynch system calls -- which need to return a "final" error code, along with the message that the call has completed.

[Combuster]

I'm missing the "just carry" option. My kernel's in assembly and everything in there uses CF to communicate success state, nothing more. Basically the same way how the bios does things.

If I want to communicate that to high level languages, I just put in a SBB EAX EAX to convert the output. Which essentially means "non-zero on error"

[edfed]

thanks for reply.

carry and positive value is assumed to contain the carry only state.
positive error code is an option.

negative error code too.

there are 5 cases for carry or (negative xor positive). i only poll the 3 most common cases i cross in code.

as a conclusion, i can just say it will support at least 3 different errors schemes.