Date:	Wed, 11 Mar 1998 11:48:49 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To:	Nate Eldredge <eldredge AT ap DOT net>
cc:	djgpp workers list <djgpp-workers AT delorie DOT com>
Subject:	Re: errno constants in <errno.h>
In-Reply-To:	<199803110141.RAA22234@adit.ap.net>
Message-ID:	<Pine.LNX.3.93.980311113653.27664A-100000@acp3bf>
MIME-Version:	1.0

On Tue, 10 Mar 1998, Nate Eldredge wrote:

> At 01:10  3/10/1998 +0200, Eli Zaretskii wrote:
> >Yes, errno doesn't have to be an lvalue.  A case in point is a 
> >multi-threaded environment, where you'd like each thread to have its own 
> >errno.
> 
> *Really?* 

No. I hate to say it, but Eli's wrong here. To quote the ANSI Standard (as
cited in 'The Standard C Library' by P.J.Plauger), in Paragraph 7.1.4
regarding errno.h: 

-----------
The macros are [...]
   errno
which expands to a modifiable lvalue* that has type int, [...].
It is unspecified wether errno is a macro or an identifier declared with
external linkage.

[The footnote referenced by '*':] 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() ).

-----------

In other words: it's always an lvalue, but not necessarily a simple
variable.

> The scheme I saw suggested was to do:
> 
> errno = 0; /* or EOK */
> y = sqrt(x);
> if (errno == EDOM) ...

This scheme happens to be explained in the following footnote in the
Standard, yes. But then, there *have* to be better ways of handling such
conditions. Like in: get a SIGFPE and catch that, or whatever.  Hardware
support is very much needed in this kind of work, if you ever want to do
it fast. Setting and checking errno (or equivalently: checking the
arguments) for each and every mathematical operation is simply too slow in
the long run. 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -