rfg@paris.ics.uci.edu (Ronald Guilmette) (02/15/90)
// cfront 2.0 bug 900210_01 // The following c++ code causes cfront to generate C code that will be // rejected by any sane C compiler. // The problem seems to be that cfront is generating a conditional // expression using operator ?: where the condition being checked // is merely whether or not the object has been allocated successfully // by "new". If not, the entire conditional expression yields the value // of the final "expression" in the constructor (in this case, a member // function pointer value which is represented in C as a structure) // whereas if the allocation was unsuccessful, the value 0 is yielded. // For the following case, the value yielded by the *entire* conditional // expression is never even used in the generated code, but the type // mismatch between the second and third operands of the ?: trinary operator // (in the generated code) cases the entire ?: expression to be invalid. // Cfront knows that this could be a problem, and uses a special trick // to avoid the problem when and if the final expression in the constructor // body yields a user-declared structure. Unfortunately, it forgets to do // this also for member function pointers (also represented as structs in the // generated C code). struct struct0 { }; typedef (struct0::*MFP)(); MFP global_mfp; struct B { B (MFP mfp) { global_mfp = mfp; } }; void foo() { new B (global_mfp); } int main () { return 0; }