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; }