"Boehm, Hans" <hans.bo...@hp.com> writes: > 1) Is it intended that inconsistent use of -fexceptions can cause > pthread cleanup handlers to be skipped (since exception based > cleanup is not invoked if thread exit is triggered from a context > without exceptions), thus usually breaking code relying on > pthread_cleanup handlers?
I don't know if I would use the word "intended," but I think this is an expected and unavoidable consequence. > 2) If so, would it be appropriate to document that behavior? In > particular, several other options in the gcc manual currently > indicate that they introduce binary compatibility issues, while this > one does not. This does seem to be basically a binary > incompatibility issue. Well, properly speaking, I don't think there is any binary incompatibility in what gcc generates. Code compiled with and without -fexceptions can interoperate perfectly well. I can see that the way in which glibc uses _EXCEPTIONS to decide how to handle pthread cleanups introduces an incompatibility, but I think that is more an issue of how the compiler is being used. Of course more documentation is normally good, but in this case what would the new documention say? It seems that it would amount to something like "If you compile code without exception support, then any exception handlers in that code will not be run." It seems almost tautological. I'm not trying to pick nits here. glibc has chosen to implement a cleanup mechanism which assumes that the code is compiled entirely with or entirely without exception support. That's a choice made by the glibc maintainers, and any restrictions that imposes are part of glibc, not gcc. gcc is, of course, used with libraries other than glibc, which may or may not have similar problems. I think gcc is making a reasonable choice in permitting exceptions to be enabled or disabled as the user prefers. > 3) If not, any chance of fixing this somehow? I don't really see how. Do you have any suggestions? > 4) Is the use of the __EXCEPTIONS macro in the library considered a > stable part of the library interface? Is it reasonable to work > around this problem by explicitly undefining it in user code? gcc will reliably define _EXCEPTIONS as 1 when exceptions are supported, and will reliably not define _EXCEPTIONS when exceptions are not supported. I can't speak to the library interface. Ian