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