Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 + RN 4.3; site inset.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!ukc!icdoc!ist!inset!jmc From: jmc@inset.UUCP (John Collins) Newsgroups: net.lang.c Subject: Bug in some versions of PCC Message-ID: <683@inset.UUCP> Date: Tue, 17-Sep-85 13:38:03 EDT Article-I.D.: inset.683 Posted: Tue Sep 17 13:38:03 1985 Date-Received: Fri, 20-Sep-85 06:03:28 EDT Reply-To: jmc@inset.UUCP (John Collins) Organization: The Instruction Set Ltd., London, UK. Lines: 39 Xpath: icdoc ivax I hit a nasty bug compiling a lex-generated program recently. The program had statements of the form return (x = y, constant); where "constant" was > 256 I tracked it down to the compiler, where in cgram.y the constant is handled by lines of the form | ICON { $$ = bcon(0); $$->tn.lval = lastcon; ...... the routine "bcon" in trees.c is supposed to work out the size required for the constant - and in this case it always gives a char. Somewhere along the line in a COMOP node the constant gets lopped down to a single byte. There is a further bug in trees.c, in that the node is created with a 0 in and the argument is not tested. I see that later versions of the compiler drop the fiddling in bcon, but retain the cgram.y code. They are also more careful in handling the COMOP node later on. In my version of the compiler I fixed 'bcon' and changed the cgram.y statements to read $$ = bcon(lastcon); and the problem went away (and the compiler still works). Any comments? -- John M Collins ....mcvax!ist!inset!jmc Phone: +44 727 57267 Snail Mail: 47 Cedarwood Drive, St Albans, Herts, AL4 0DN, England.