Gunnar Evermann writes: Gunnar> I think this will hit *many* of our users with the release of 21.0, as Gunnar> nowadays gcc >=2.8 is pretty widespread. We should write an entry for Gunnar> PROBLEMS (in fact I will do that later today!), but I think almost Gunnar> nobody reads that file anyway. People should. As well as the NEWS file. Gunnar> This will give us a nice answer for comp.emacs.xemacs to the crash Gunnar> reports ('we told you so!'), but doesn't prevent the crashes. Add this to the jargon file: `RTFPF' :-) Gunnar> Isn't there anything else we can do? like, some smart logic in Gunnar> configure that screams at the user when he's trying such a build or Gunnar> some nifty #pragmas in search.c to work around this or a fix for Gunnar> gcc... In general, I think it's a bad idea to increase the hack complexity of one application in order to fix another application. Obviously, there are exceptions. Personaly, I see at least three of them: - you need extensively a feature which is broken by concept (e.g. X11 doesn't support loosing a display connection even if another one is still ok). - you *absolutely* need a feature, but some implemetations are broken. - you need a feature, and you have nothing but one only implementation (e.g. a system call). In those cases, it is acceptable to hack your own app. However, in the case of a compiler bug (especially when it can be avoided by tuning the compiler itself), I think it's a bad idea. Users can avoid it at a low cost, if they don't read the PROBLEMS file, well, next time they'll know, and hopefully, some of them will scream at the compiler developpers. So we cumulate 3 pedagogical advantages ;-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19