wmm@sdti.UUCP (William M. Miller) (09/30/87)
I recently ported cfront v1.2 to OS/2. Most things worked pretty well, but compiling anything that included <signal.h> bombed with a segment fault. I managed to get a very small repeatable test case: int (*signal(int, int (*)()))(); I tracked the faulting statement down to a line in name::normalize in the file norm.cpp (I've forgotten what naming conventions are used in Unix to designate a C++ file, but since Guidelines uses ".cpp" under DOS, I use the same under OS/2). It's pretty hard to figure out all the logic of something as complicated as cfront with only the internal comments for documentation (is there a PLM available? If so, it didn't come with my copy of the package), especially when they say things like "//HORRIBLE FUDGE: fix the bad grammar" and "//error('d',"%s: mis-analyzedP to F e==%d",string,e)"! However, after a few hours of staring at the code, I detected what appears to be the error causing the problem: the code at "case PTR: case VEC:" figures out the type to which the base points or of which it is a vector, sets "t" to that type, and goes back to the "switch(t->base)" statement; however, the code at "case FCT:" does not make use of the new value of "t" but still uses the original value of "f2". In the case at hand, "f2" points to a "ptr" struct while the code expects it to point to a "fct" struct. I therefore made the following change: ***** norm.org case FCT: { Pexpr e = f2->argtype; //error('d',"%s: mis-analyzedP toF e==%d",string,e); ***** norm.cpp case FCT: { Pexpr e = Pfct(t)->argtype; //error('d',"%s: mis-analyzedP toF e==%d",string,e); ***** Can anyone confirm that this is a legitimate fix? It seems to "work," but I'm afraid of breaking some other case that hasn't shown up yet. -- Non-disclaimer: My boss and I always see eye-to-eye (every time I look in the mirror). ...!genrad!mrst!sdti!wmm