Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ll-xn!mit-eddie!husc6!necntc!necis!mrst!sdti!wmm
From: wmm@sdti.UUCP (William M. Miller)
Newsgroups: comp.lang.c++
Subject: Possible bug fix to cfront 1.2
Message-ID: <130@sdti.UUCP>
Date: Wed, 30-Sep-87 01:21:09 EDT
Article-I.D.: sdti.130
Posted: Wed Sep 30 01:21:09 1987
Date-Received: Sun, 4-Oct-87 21:38:11 EDT
Reply-To: wmm@sdti.UUCP (William M. Miller)
Organization: Software Development Technologies, Sudbury MA
Lines: 42

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