In article <CFw5x6.3Is@oceania.com> jim@oceania.com (Jim Mackraz) writes:
>There's a distinction to be noted before these questions become answerable.
>
>Non-reentrant code is one thing:
> i = a; ++i; a = i;
>
>But hidden non-re-entrant compiler tricks is another.  With some compilers
>"in the past," this C code was not re-entrant:
>
>static BOX b1;
>static BOX b2;
>
>BOX chooseBox( int i )
>{
> if ( i == 0 )
>  return b1;
> else
>  return b2;
>}
>
>Note:  The structure BOX is integers left/top/width/height.
>
>The deal was that some compilers returned structures from functions by stashing
>them "temporarily" in a static location, before copying them back to the caller
>who said:
> theBox = chooseBox( 0 );
>
>Two pre-emptive threads calling this function can easily trash one-another's
>return value.

Yes, exactly.  And that's why I think that the X3J11 (ANSI C) standardization
committee effectively ruled that "conformant" implementations must choose
a different (reentrant) way of implementing the return of structure-typed
values.

>Presumably, you can write re-entrant code with any compiler, once you know the
>gotcha's.

But you see that's just the problem.  I (and others) wish to be able to
write PORTABLE reentrant code which will still *act* reentrantly whenever
it is compiled by any standard conformant compiler... and we don't want to
have to find (or know) all of the quirks of all of the different "conformant"
compilers out there just to be able to do this.  Rather, we would like the
ANSI/ISO C++ standard to effectively force compiler vendors to either
implement things in a reentrant manner or else forgo the cachet of any
claim that their implementations are "standard conformant".

>My shallow understanding of C++ does not induce me to speculate on whether
>there are any more constructs (e.g., references) which are being implemented
>to generate non-re-entrant code.

As previously discussed here, the HP implementation currently does not
implement exceptions in a reentrant manner.  (And by the way, that SHOULD
NOT be considered a knock against HP... They have one of the few compilers
around that even *tries* to fully implement C++ exceptions!  They should
be commended for their pioneering efforts in this area.)

I (for one) hope that the HP implementors (and all other implementors) do
seek in future to do their level best to implement ALL features of the
language in a reentrant manner, and I further hope that the forthcoming
C++ standard will provide all implementors with sufficient encouragement
to tackle this difficult task.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------