Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!hp-pcd!orstcs!nathan
From: nathan@orstcs.UUCP (nathan)
Newsgroups: net.lang.c++
Subject: Re-entrancy Re-visited
Message-ID: <34200005@orstcs.UUCP>
Date: Sun, 2-Mar-86 17:29:00 EST
Article-I.D.: orstcs.34200005
Posted: Sun Mar  2 17:29:00 1986
Date-Received: Fri, 7-Mar-86 05:44:17 EST
Organization: Oregon State University - Corvallis, OR
Lines: 57
Nf-ID: #N:orstcs:34200005:000:2710
Nf-From: orstcs!nathan    Mar  2 14:29:00 1986

"That turns out not to be the case."	-Niven & Pournelle

Under certain FORTRAN compilers, I can write a clean, recursive
Hoare quicksort.  It would not be at all portable.  FORTRAN is
not a recursive language.

Under certain C compilers, I can write a complex-number library
whose functions are usable both in main-line code and in signal
routines.  It would not be at all portable.  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.

If, in the language specification, it doesn't say that
interrupts won't mess up mainline code's variables, then I as
a programmer can't count on that fact -- and any program I write
which needs it is immediately, irreparably nonportable.

C++ was intended to address the needs of implementors
of large systems.  The Unix kernel is one such system.
The Unix kernel avoids use of structs as return values.
Are we to avoid returning "class" items in C++ programs,
except in constructors?

I understand that addressing this issue raises some sticky
implementation issues, *all* related to use of C as the
intermediate language representation.  I do not think that it
therefore deserves to be swept under a rug.

After all, the issue is not intractable.  Let's call a bug a bug.
For instance, one could define an explicit subset of C++, called
"C++ but not re-entrant".  Compilers that bypass the C stage, or
are built around a re-entrant C compiler, need not be so hobbled
and could then be called full "C++".

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.
The extra argument wouldn't bother (most) pcc library routines.
C-library calls still wouldn't be re-entrant, but C++ ones would.
The only difficulty would be in object compatibility with other
(unbuggy) C++ compilers.

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.

	Nathan C. Myers
	{ tektronix | hplabs!hp-pcd }!orstcs!nathan  OR nathan@oregon-state