draves@harvard.ARPA (Richard Draves) (02/11/85)
The following program causes our 4.2BSD lint to core-dump:
struct { a x; };
typedef int *b, *a;
struct { b y; a z; };
I don't have a fix.
Rich
--
"If I am conceited, it is the conceit of an amazing man
who has never found any surpassing himself."
Al-Mutanabbiguy@rlgvax.UUCP (Guy Harris) (02/12/85)
> The following program causes our 4.2BSD lint to core-dump: > > struct { a x; }; > typedef int *b, *a; > struct { b y; a z; }; > > I don't have a fix. I tried it with PCC (which also drops core) on our system. There is a bug in PCC, probably in the error recovery rules in the grammar, that causes the compiler to think it's processing an initialization when it isn't. Since it hasn't run all the proper code to handle the initialization, some global pointer isn't properly initialized, but is dereferenced by the code that thinks it's processing an initialization, and it dies. There may be a fix, but it's probably a lot of work to find it (including tweaking the error handling rules in the grammar). Lots of syntax errors cause this problem. You might try putting the typedef before the "struct { a x; };" declaration so that it knows about the typedef before trying to use it. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
edhall@randvax.UUCP (Ed Hall) (02/14/85)
I've seen LINT or PCC dump core on a number of occasions, although in all cases the program being processed was incorrect and error messages were printed before the dump occured. Fixing the error that caused the error message(s) also eliminated the core dump. Thus in and of itself the problem isn't much more than a nuisance. On the other hand, the ``bad initialization'' error message is a good example of the often cryptic (and in this case incorrect) error messages that PCC emits. In a word, error reporting in PCC is abysmal. In this particular case, I suspect that the problem lies in how the grammar handles ``old-fashioned initializations''; if instead of making allowances for this by just issuing a warning the compiler *required* an equal-sign before the initializer, the problem would likely go away. In fact, I'd vote for such a change, and not force the grammar to allow for the ``old-fashioned initialization'', except to flag it as an error. Backwards-compatability isn't always a good idea, especially when it involves something as trivial as this (and has such bad effects on parsing). Comments? -Ed Hall decvax!randvax!edhall
ado@elsie.UUCP (Arthur David Olson) (02/15/85)
> The following program causes our 4.2BSD lint to core-dump: > struct { a x; }; > typedef int *b, *a; > struct { b y; a z; }; Index: src/mip/pftn.c Fix Description: Feeding outre source to "lint" or "cc" can cause core dumps using either the 4.1bsd or 4.2bsd versions of the programs. Repeat-By: echo "struct { a y; a z; };" > file.c cc file.c lint file.c Fix: ed mip/pftn.c /determine if name/a #ifndef OLDVERSION if (paramno > 0) #endif . w q -- Lint is an Oscar Madison trademark. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX and Elsie are Digital Equipment and Borden trademarks
guy@rlgvax.UUCP (Guy Harris) (02/17/85)
> I've seen LINT or PCC dump core on a number of occasions, although in > all cases the program being processed was incorrect and error messages > were printed before the dump occured. Fixing the error that caused > the error message(s) also eliminated the core dump. > On the other hand, the ``bad initialization'' error message is a good > example of the often cryptic (and in this case incorrect) error messages > that PCC emits. > In this particular case, I suspect that the problem lies in how the > grammar handles ``old-fashioned initializations''; I suspect you're right. The problem is that PCC gets confused, probably due to error recovery, and thinks it's processing an initialization. Unfortunately, it assumes that some routine that is called earlier in the processing of an initialization has been called, and has set a global pointer to point somewhere meaningful; alas, it has not, and it dies trying to dereference that pointer. > if instead of making allowances for this by just issuing a warning the > compiler *required* an equal-sign before the initializer, the problem > would likely go away. In fact, I'd vote for such a change... As of System V, all the old syntax (initializers without "=", the "=+", "=-", "=*", etc. operators) has, indeed, disappeared. Anybody out there with a S5 compiler care to try some of the guys that cause earlier PCCs to drop core? Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
wcs@ho95b.UUCP (Bill Stewart) (02/21/85)
> As of System V, all the old syntax (initializers without "=", the "=+", > "=-", "=*", etc. operators) has, indeed, disappeared. Anybody out there > with a S5 compiler care to try some of the guys that cause earlier PCCs to > drop core? > > Guy Harris > {seismo,ihnp4,allegra}!rlgvax!guy Unfortunately, the old =- is still with us in System V, sort of: main(){ int j; j=5; j=-1; } Under System V, both lint and cc complain that the j=-1 line is ambiguous, and select the assignment-op. Then they reject it, and don't produce object code. Under System V Rel 2, it finally lets you say j=-1; when you mean j = (-1); - the lint comment is that the assignment is ambiguous, but the unary-op is chosen, so it does it right this time. Bill Stewart P.S. I didn't remember the old init syntax, so I haven't tried it. -- Bill Stewart AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ...!ihnp4!ho95b!wcs