Date: 06 May 2003 11:29:01 -0700 From: Mark Mitchell Subject: Re: __attribute__((cleanup(function)) versus try/finally Message-Id: <1052245742.2583.315.camel@doubledemon.codesourcery.com> References: MIME-Version: 1.0 Content-length: 1836 On Tue, 2003-05-06 at 06:20, Gerald Pfeifer wrote: > Michael Matz asked that the SC addresses this issue, and I'm forwarding > his message below. I have also suggested to provide more detailed > technical arguments which I'll forward as well. > > For those that didn't follow gcc-patches, there has been strong > disagreement on how to implement exception handling in C for some > time now: > > o RTH (and others) are strongly in favor of try/finally, which is > implemented by several others compilers. > > o Mark (and others) are against adding try/finally and favor adding > a different extension: __attribute__((cleanup(function)) which is > "lighter" in a sense. I think RTH accepts the attribute solution as well. He would prefer try/finally, as I would prefer no extension, but I think we are both willing to accept the attribute. A key point (which seems to be missed by most people in this dicussion) is that you do not need a language extension to get the correct behavior. You simply need to have the exception-handling mechanism aware of the C cleanup stack. In fact, that solution delivers maximum performance: (1) C functions do not need to have handler code inserted. (2) You do not have to transfer control from the EH mechanism to the stack frame of the caller in order to perform the cleanups. The __attribute__ solution can be implemented with the same optimal performance, but that does not seem to be the way in which people intend to implement it. The try/finally solution cannot be implemented with this same performance; it will, in fact, exact a performance price, in terms of both code space and the speed at which cleanups are run, on all systems. On systems with setjmp/longjmp exceptions, both costs will be very high indeed. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com