OSDev.org

This is very specific, and a bit difficult to explain, and quite likely impossible, but here goes. Perhaps some C cracks out there have an idea...

I want to implement <errno.h>. (My hobby project is implementing a Standard C library.)

The naive way to go about it is:

Code: Select all

// in <errno.h>
extern int errno;

// in some .c file
int errno = 0;

This works. But it has one disadvantage: If a math library function is called, it always has to query the FPU status after execution to set errno as appropriate. This stalls the FPU in math-heavy applications.

The C standard endorses lazy evaluation of errno by making it a macro instead:

Code: Select all

int * __errno();
#define errno *__errno()

This way, errno is only "set" when its value is actually requested:

Code: Select all

// "__errno()" returns the location of the current errno value,
// the "errno" macro turns it into a value.
x = errno;

Given some logic in the rest of the library, the FPU status needs only be queried if the last library function called was actually one using the FPU, and the value of errno is actually requested.

So far, everything is fine. But it's the other way around that is giving me headaches:

Code: Select all

errno = 0;

The value of errno is not requested at all. But __errno() does not know that, and will query the FPU status if the last library function called was using the FPU.

Right now I don't see a way to avoid that (i.e., have the errno macro or the __errno() function somehow work differently depending on whether they are used to the left or the right of the assignment operator), and am almost content to accept this.

But perhaps any of you OSDev'ers has a brilliant idea?

The C standard endorses lazy evaluation of errno by making it a macro instead:

Brendan wrote:If there was no error then errno must be unchanged, so you must examine the FPU status to determine if errno (or __errno) should be changed or not.

Are you sure that C endorses lazy invalidation in this case, and that errno isn't a macro for other reasons (e.g. so that the macro can resolve to an address in thread local storage if someone includes pthreads)?

[...] errno
which expands to a modifiable lvalue171) that has type int, the value of which is set to a
positive error number by several library functions.

171) The macro errno need not be the identifier of an object. It might expand to a modifiable lvalue
resulting from a function call (for example, *errno()).

Solar wrote:

Brendan wrote:If there was no error then errno must be unchanged, so you must examine the FPU status to determine if errno (or __errno) should be changed or not.

Yes, but the lazy evaluation allows me to examine the FPU status only when errno is actually queried after the function. In a series of math functions, where only the last one is followed by a check of errno, I only have to check the FPU status once, instead of after each individual function.

GCLIB wrote:The initial value of errno at program startup is zero. Many library functions are guaranteed to set it to certain nonzero values when they encounter certain kinds of errors. These error conditions are listed for each function. These functions do not change errno when they succeed; thus, the value of errno after a successful call is not necessarily zero, and you should not use errno to determine whether a call failed. The proper way to do that is documented for each function. If the call failed, you can examine errno.

Solar wrote:

Are you sure that C endorses lazy invalidation in this case, and that errno isn't a macro for other reasons (e.g. so that the macro can resolve to an address in thread local storage if someone includes pthreads)?

Positive.

7.5 Errors, paragraph 2:

[...] errno
which expands to a modifiable lvalue171) that has type int, the value of which is set to a
positive error number by several library functions.

171) The macro errno need not be the identifier of an object. It might expand to a modifiable lvalue
resulting from a function call (for example, *errno()).

Solar wrote:The idea that this can be used for lazy evaluation with regards to FPU operations is from P.J. Plaugher's "The C Standard Library". Plaugher being a long-time member in the C standard committee, I assume he knows what he's talking about.

/* Declare the `errno' variable, unless it's defined as a macro by
   bits/errno.h.  This is the case in GNU, where it is a per-thread
   variable.  This redeclaration using the macro still works, but it
   will be a function declaration without a prototype and may trigger
   a -Wstrict-prototypes warning.  */
#ifndef errno
extern int errno;
#endif

This works. But it has one disadvantage: If a math library function is called, it always has to query the FPU status after execution to set errno as appropriate. This stalls the FPU in math-heavy applications.

Combuster wrote:Second problem (if you thought about it) - have you thought about the fact that non-fpu functions might yield an change in errno, and you want to make sure that errno reflects the latest error. So you can't blindly check the FPU status word in any lazy scheme and set errno accordingly.