Re: Necessity of multi-level error propogation
On Mar 12, 11:20 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Jeff Schwab:
James Kanze wrote:
[...]
For a very liberal meaning of "return code". You can use out
parameters, global variables (ever heard of errno?)
errno isn't a global variable
errno is a global variable.
It certainly behaves like one.
, it's a macro.
And yes, errno is required to be a macro.
In C++. Curiously, both C and Posix also allow it to be an
indentifier with external linkage; until recently, Posix
actually required it to be declared:
extern int errno ;
In the first case 'errno' refers to a concept and/or bottom
level implementation of that concept.
In the second case 'errno' refers to a very limited tech
detail view that few if any find useful to know about, but the
purpose of which is to provide the first case's concept in a
way such that people don't have to worry about the details.
On the system I'm using to post this message, it maps to a
function call.
Really?
The name 'errno' has to behave as a direct reference to a
variable, so in C it can at most map to an expression that
dereferences the pointer result of a function call (but it can
there not map to a direct function call).
In C++ it can conceivably map directly to a function call, but
it would be rather silly to implement it differently in C++
and C.
Under Solaris, its definition depends on whether the -mt option
was given; in single threaded code, it's a global variable, in
multithreaded, it expands to (*(__errno())).
Curiously enough, I've been unable to find anything in Posix
concerning its semantics in a multithreaded environment;
typically, it resolves to a thread local variable (behind the
function call), and of course, anything else would make it
totally unusable. But I'm curious about things like &errno and
errno = 0. I can't find anything in any of the standards to the
effect that in multiple uses of errno (in the same thread), the
lvalue actually refers to the same int, although of course, if
this were not the case, the common sequence of setting errno to
zero, then calling a function and examining it wouldn't work.
(I suppose that there are some implicit requirements along these
lines, based on the fact that some standard functions set errno,
and expect you to be able to read the value they've set.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34