Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sftig.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!sftig!lr
From: lr@sftig.UUCP (L.Rosler)
Newsgroups: net.lang.c++
Subject: Re: structure return - reentrancy
Message-ID: <702@sftig.UUCP>
Date: Wed, 19-Mar-86 22:13:32 EST
Article-I.D.: sftig.702
Posted: Wed Mar 19 22:13:32 1986
Date-Received: Fri, 21-Mar-86 06:05:10 EST
References: <5080@alice.UUCP>
Organization: AT&T Bell Laboratories, Summit, NJ
Lines: 32

> Bjarne Stroustrup writes:
> So why don't I do that for all structure returning functions? Compatibility.
> Also, I hope/expect that eventually all C compilers will do it right.
> Lobby your local ANSI C representitive.

Lobbying isn't needed.  Here is the text from the latest draft
(February 14, 1986) describing the behavior of functions under
interrupts:

"2.2.3 Signals and interrupts

     Functions shall be implemented such that they may be interrupted
at any time by a signal, and may be called by a signal handler with
no alteration to control flow, to function return values, or to objects
with automatic storage duration belonging to earlier invocations.
All such objects shall be maintained outside the image of the function
itself, on a per-invocation basis.  The function image may not be
modified during its execution.

     The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration."

So implementations of structure-returning functions that use static
return areas are not reentrant and not standard-conforming.

Larry Rosler
Editor, X3J11
AT&T
190 River Road
Summit, New Jersey 07901
201-464-3321
ihnp4!attunix!lr