🚀 go-pugleaf

volpe@bart.crd.ge.com (Christopher R. Volpe) wrote:

|>In article <4alnjh$r8l@usenet.pa.dec.com>, diamond@jrd.dec.com
(Norman Diamond) writes:
|>|>In article <DJEADH.HwC@nntpa.cb.att.com>, ka@socrates.hr.att.com
(Kenneth Almquist) writes:
|>|>>I've got some code which uses longjmp() to jump to error handling
code.
|>|>>Is it safe to assume that longjmp will not modify errno?
|>|>
|>|>Unfortunately the standard takes great pains to make this
assumption unsafe.
|>|>
|>|>ANSI Classic section 4.1.3, page 98 lines 27 to 28, make errno
expand to a
|>|>modifiable lvalue with type int but do not make it an object.
This intent
|>
|>A modifiable lvalue is never an object. They are conceptually two
different
|>things. An "object" is a region of storage. An lvalue is a syntactic
entity
|>that denotes an object. 
|>
|>|>is demonstrated by footnote 89:  "The macro errno need not be the
identifier
|>|>of an object."
|>
|>So what? A modifiable lvalue, whether it is a simple identifier with
external
|>linkage, or a complicated expression involving function calls and
pointer
|>dereferencing, denotes an object, by definition. There is real
storage
|>associated with whatever "errno" expands to. _That's_ an object.
Identifiers
|>are not objects, ever.
|>
|>Therefore, whatever errno denotes is an object, and that object is
accessible
|>through the use of the errno macro, and therefore must have its
value as of
|>the time longjmp was called.
|>
|>However, Mark Brader writes:
|>>So both the value that you get if you examine errno and the
location
|>of
|>>the int object that errno seems to be may actually be computed
dynamically
|>>by reference to objects *not* accessible to the caller of longjmp()
or
|>>setjmp(), and the guarantee in 7.6.2.1 does not apply.
|>
|>Ok, so a later invocation of errno may denote a *different* object
from what
|>it did denote, or would have denoted, before the longjmp. That may
be
|>sufficient for allowing the value of "errno" to change. But I do
believe that
|>the wording of the standard (ISO 7.6.2.1 "All accessible
objects...") makes it
|>clear that if "&errno" before longjmp equals "&errno" after longjmp,
then
|>the value of errno cannot change across longjmps.
|>
|>Or have I made a mistake somewhere?

Unfortunately, I think you have made a mistake.  Assuming Mark's
interpretation is correct (and I can find nothing in the standard that
disallows it) even if errno has the same address on two invocations it
may not refer to the same object.  Consider the following
implementation of errno:

	#define errno (*__errno())

	int* __errno()
	{
	  static int e = 0;
	  static int* eptr = &e;

	  e = *eptr;

	  if (eptr != &e)
	    free(eptr);

          eptr = malloc(sizeof *eptr);
	  if (eptr == 0)
	    eptr = &e;

	  *eptr = e;
	  return eptr;
	}

Assuming we don't run out of heap memory, this returns a pointer to a
different object each time it is called, but it certainly possible
that malloc() could allocate the memory just freed and successive
calls return the same address.

Of course this is a ridiculous implementation, but I can't find
anything in the standard that forbids it.


Michael M Rubenstein