🚀 go-pugleaf

> 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)