🚀 go-pugleaf

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

: 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?

A possibility - rather perverse:

Does the object for errno have to exist at the time the longjump is made?
Could one have an implementation where an object to hold the value of errno
only exists when it is needed. When it is not needed the compiler generates
code to save the value of errno somewhere else (eg writes it to a file) and
deletes the object. Next time it is needed it creates a new object and reads
the value back (eg from the file). Thus the object does not have to exist
when the longjump is made. If you take the address of errno and store that
away somewhere then you would probably force it to stay in existance.

[Note this requires errno to expand to something that is not standard C and
some special compiler support (garbage collection and a persistant heap?)
- but there is nothing wrong with that.]




--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom