Re: union type is evil, redux

Dmitry> Thanks for the best wishes :-) "Compiler bug" is too Dmitry> strong and relatively unlikely claim OK, so let's stop talking about compiler "bugs" and talk about compiler _behavior_. Compiler _behavior_ _has_ been proven by Ben in the past, and the compiler writers refused to change it. I don't think it's unreasonable, when combined with the circumstantial evidence of "crash goes away with --use-union-type=no", to presume that unions still don't work as XEmacs code expects them to. The question then is "Will the compiler change its behavior, or must XEmacs change its code? If the latter, should we try to conform to the standard, or should we deprecate the troublesome construct since we already have a working alternative?" From Ben's point of view, the answer is obvious. Dmitry> If somebody does not follow the strict standard specs (no Dmitry> matter how logical or obvious his/her intentions was), Dmitry> it's his/her bug, not the compiler problem. It _is_ a compiler problem (in a different sense), because a feature that the vendor has gone to some effort to support (a) cannot be used and (b) decreases user confidence in the reliability of the compiler for the user's purpose. If the GCC developers want to say "we have good reason for doing it this way, and therefore it's unlikely to change", I can't object to that. But it's reasonable then to deprecate use of --use-union-type in XEmacs, which is all that's in question here. Dmitry> Again, it's just words. Yes, but it's the _vendor_'s words. Ben says he demonstrated the behavior, they admitted it, and they refused to change it. Dmitry> But "fixing" the bugs by avoiding some language constructs Dmitry> (without any guarantee that the bug won't reveal itself in Dmitry> other place) does not seem to be very appealing to me... It's not appealing to me or Mike Sperber, either. But there's never a guarantee that you've actually fixed a bug. So the question is "is it worth trying harder to be more sure?" Ben, who has already worked hard on the problem (or a similar one), says "No!" Look, what Ben is saying AFAICT is that where currently we do Lisp_Object foo (Lisp_Object); Lisp_Object bar (Lisp_object x) { Lisp_Object y; y = foo(x); return y; } etc all over the place, it works correctly. That is, with typedef int Lisp_Object; it fails _intermittently_ with the union type. In order to make the union type work, probably we'd have to do something like #define a LISP_ASSIGN macro in order to enforce explicit temporaries and replace all object assignments with macro calls Lisp_object bar (Lisp_Object x) { Lisp_Object y; LISP_ASSIGN(y,x); return y; } This is _not_ a win. And replacing just the "dangerous ones" is GCPRO all over again. Dmitry> Sorry if my message seems to be offensive for anybody. I don't consider it offensive, and I doubt Ben does. But I think you are leaving too little responsibility to the compiler writers. It is not a purely technical problem. It is also a matter of user confidence. Theirs to lose.... And remember, where standards don't dictate semantics, it's often[1] because it's unclear what semantics are appropriate. If users can make a case that certain semantics are useful and consistent with the standard, I think that compiler writers, as well as the users, can (indirectly) benefit from using those semantics. Footnotes: [1] Of course, not always. The order of evaluation of arguments is an immediate counterexample; that ambiguity is dictated by efficiency. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.