[llvm-dev] try/catch with std::errc::bad_address

[Herbie Robinson via llvm-dev]

I was curious how std::errc::bad_address was handled; so, I made up this 
test case (fault_test.cpp):

#include "fault_test.hpp"
#include <exception>
#include <system_error>

static int n;

void fault_test(int *p)
{
   std::error_code ec = make_error_code(std::errc::bad_address);
   std::system_error e = std::system_error(ec);

   try
   {
     n += *p;
     std::cout << "No fault.\n";
   }
   catch(const std::system_error &e)
   {
     std::cout << "Caught the fault.\n";
   }
}

int get_sum(void)
{
   return n;
}

The fault isn't caught by the catch clause, It just faults in the try 
compound_statement (running it under Xcode).  Thinking about this a 
little bit, I can see why anything implementing unwinding using the GGC 
algorithm would decline to implement this (because the exception usually 
wouldn't be handled and that would be pretty rude debug behavior).

I was wondering if:

1,  The Windows SEH algorithms can handle this?

2.  LLVM is prepared to handle exceptions arising out of anything that 
happens in the try compound statement or only calls?

The reason I ask is that other OSes that one might port to do support 
catching general faults in their unwind mechanisms.  I believe Multics 
implemented that in pl1 way back when:  The idea is to keep your kernel 
gates as fast as possible by just making sure output arguments point at 
things the user is allowed to modify and letting the exception handler 
catch faults arising from bad reads.

The other files for the test:

fault_test.hpp:

#include <iostream>

extern void fault_test(int *p);
extern int get_sum(void);

main.cpp:

#include "fault_test.hpp"

int main(int argc, const char * argv[]) {
   // insert code here...
   fault_test(nullptr);

   std::cout << "Sum = " << get_sum() << "\n";
     return 0;
}