🚀 go-pugleaf

>With that said, I would like to address an area in which I
>hope there is still room for flexibility: re-entrancy. 
>Modern C is in fact only partially re-entrant, and the
>standard library is (in many routines) not at all.

Let me second this motion!  The current implementation of
structure-returning functions in C is an accident waiting to happen, and
is inefficient as well.  I have a MASSCOMP with their "Real-Time" UNIX,
which has an asynchronous trap (AST) facility similar to that of RSX-11.
Its really handy, but I wonder how many programmers are aware of the
potential timing-dependent bugs that can occur because of the
non-reentrancy of the code produced by the C compiler.  With more talk
of adding real-time features to UNIX, its time to fix this defficiency.

As for how to correct this in C++, it appears that Bjarne Stroustrup has
already thought about this.  See Section 17 of his article "Operator
Overloading in C++", AT&T Bell Laboratories Technical Journal, Vol. 63,
No.8, October 1984 (I think).  Basically, the idea is that since the
caller knows that a structure is to be returned, it can pass the address
of where it wants the result placed in as a "hidden" argument (like
"this" is handled now for member functions) to the called function.  The
called function knows it is returning a structure, so it expects the
hidden result pointer and copies the local variable that appears in the
function return to this area.  The C++ translator could thus translate
structure-returning functions and function calls into C code that
doesn't use structure-returning functions, without any change to the C++
syntax.  I don't think C++ Release 1.0 does this, however.
-- 
---
	Keith Gorlen
	Computer Systems Laboratory
	Division of Computer Research and Technology
	National Institutes of Health
	Bethesda, MD 20892
	phone:	(301) 496-5363
	uucp:	{decvax!}seismo!elsie!cecil!keith