Re: patch: <bits/localefwd.h> with -fno-exceptions

[Benjamin Kosnik <bkoz at redhat dot com>]

Jason, this is an example of code that is causing problems in current CVS:

int main()
{
  int i;
  try { 
    i++;
  } 
  catch(...) { 
  }
  return 0;
}

It's dying on the catch statement.

%COMP.sh "-fno-exceptions" list09.cc
list09.cc: In function `int main()':
list09.cc:8: exception handling disabled, use -fexceptions to enable
list09.cc:9: Internal error: Segmentation fault.
Please submit a full bug report.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

After adding -fno-exceptions to CONFIG_CXXFLAGS in src/Makefile and
libsupc++/Makefile, and seeing where things are currently broken, I'm
beginning to get an idea of how I'd prefer to handle this situation.

The best approach, as far as I'm concerned, would be to transform try
and catch blocks as follows when using -fno-exceptions, so that the
library people (and the rest of g++ users, incidentally) only had to
worry about throw statements.  Ie:

	  try 
	  { 
	    delete this; 
	  } 

transformed to:

	  if (1) 
	  { 
	    delete this; 
	  } 

And

	  catch(...) 
	  { 
	  }

transformed to:

	  if (0) 
	  { 
	  }


Then the library would only need to clean up stuff like 

throw std::out_of_range("here");

we could just use inline-functions and configure hackery / soft links
to switch between a

void
__throw_out_of_range(const char* __s)
{ throw std::out_of_range(__s); }

and

unsigned long __glibcpp_exception;

void
__throw_out_of_range(const char* /*__s*/)
{ __glibcpp_exception = 5; }

or whatever.

This seems the most sane to me, it's a macro-less and debuggable
solution that allows users to painlessly transition to a world where
exception codegen issues are less of an issue, and I'd be willing to
do this work. Jason, can you meet me half-way? What are your thoughts?

-benjamin