🚀 go-pugleaf

In article bav@wcap.centerline.com, chase@centerline.com (David Chase) writes:
>
>Use of techniques not mandated by the ABI does not necessarily
>"violate" the ABI.  For instance, Sun's current C++ product uses
>PC-ranges, yet these are not discussed in the ABI.  Note that the C++
>subroutines interoperate with ABI-conforming subroutines.  Placing
>something like that in the ABI merely helps reduce the chance that
>each and every language and vendor will do something different and
>non-interoperable.

I'm afraid it does more than that. Suppose PC-ranges are not in the ABI
and a C++ program uses functions (like the C library or the X library or
a database library) which were not written or compiled as C++ and thus do
not have PC-ranges.

If an asyncronous signal occurs during execution of a non-C++ routine, and
the signal handler is a C++ routine that throws an exception, what will
happen if the stack is not in a consistent state? 

Guarantees in the C++ standard about exceptions in signal handlers would be
tantamount to saying that C++ programs cannot expect to call non-C++ functions.

The C standard does not even promise that you can call an arbitrary
function from a signal handler. How can C++ make stronger promises?

On a given platform, an implementation may provide documented
behavior for what the standard says is undefined, and in fact that is
often the case. For example, some invalid floating-point operations have
undefined behavior, but many implementations provide well-defined
mechanisms for dealing with FP errors. Most platforms define how pointer
and integer types may be inter-converted. You just can't count on these
things in portable code.

Similarly, if it made sense on a given platform to allow arbitrary code in
signal handlers, the implementation could document that fact. Requiring
such from every implementation on every platform is a different story.

---
Steve Clamage, stephen.clamage@eng.sun.com



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]