bs@alice.UucP (Bjarne Stroustrup) (03/06/86)
> Newsgroups: net.lang.c++ > Organization: Oregon State University - Corvallis, OR > Nf-From: orstcs!nathan Mar 2 14:29:00 1986 > > C is not a fully re-entrant language. > > What galls is that *most* of the language is! It's only in the > area of structure handling that the specification is too loose > to permit portability of programs which need re-entrancy. I think that there are simply a lot of sloppy implementations around. C can, and in my opinion ought to, be implemented so that programs are reentrant. The reasons for the ``sloppiness'' are mainly historical. > After all, the issue is not intractable. Let's call a bug a bug. Hear, hear. > A more difficult solution would be to work around the (quite prevalent) > bug. For example, the C code generated could allocate return-value > space in the caller's block and generate an extra pointer argument > for the C function whose C++ "antecedent" returns a struct. > The C function would copy its "return value" out via this pointer. > The calling function would use the returned pointer to access > the return value. Then even pcc-based compilers would work right. This is exactly what my latest cfront (C++ translator) does for objects of a class for which a constructor on the form X(X&) has been declared. In this case I don't even have to copy the return value, i just construct it right in the (uninitialized) object passed for that purpose. 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. > A note to Dr. Stroustrup: I hope that in harping on this point I am > not making an enemy. I think C++ is a tremendous product that > may rescue us all from almost certain Ada-ization. But as a builder > of real-time systems, I'd love to see some indication that it will > be useful (that is, portable) in what I and my kind do. Not at all. - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)
lr@sftig.UUCP (L.Rosler) (03/20/86)
> 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