Yacc action misbehaving with printf....

[Colin Brough]

I am using a yacc Pascal grammar (derived from the one available from
the comp.compilers moderator), and have run into a very puzzling
problem.  I'm not certain that the problem lies with yacc itself, but
that is where I came across it. 

The problem first cropped up under SunOS 4.1 on a Sun 4/65.  The same
behaviour has been observed under DYNIX (V3.0.17.9 NFS) on a Sequent
Symmetry, but 'goes away' on a Silicon Graphics under IRIX System V
Release 3.3.1

The following is the key part of my grammar (record types are being
declared): 
----------------------------------------------------------------------
struct_type	: RECORD field_list END
			{ $$ = (int) mk_record((struct st_list *) $2); }
		;

field_list	: fixed_part
			{ printf("\n** field_list ");
			  temporary_print((struct st_list *) $1);
			  $$ = $1;
			}
		;

fixed_part	: fixed_part ';' record_section
			{ $$ = (int) st_append_list((struct st_list *) $1,
				(struct st_list *) $3); }
		| record_section
			{ $$ = $1; }
		;

----------------------------------------------------------------------

Looks fine, gets past yacc OK, but when run the 'printf' in the
'field_list' rule produces a '0' on the screen, and nothing else (no
newline).  The 'temporary_print' function is called correctly.  I have
tried duplicating the 'printf' statement, thus:

field_list	: fixed_part
			{ printf("\n** field_list ");
			  printf("\n** field_list ");
			  temporary_print((struct st_list *) $1);

This produces:

0

**field list [output from temporary_print]

i.e. only one of the 'printf's is called correctly.  Taking away the
'printf' has no effect on the call to 'temporary_print', which is called
as is should be.  This occurs whether the 'printf' is the first output
in the program or not.  Substituting 'fprintf(stderr, ....)' makes no
difference either.

I'm calling yacc with '-dv' options, cc with '-g', and linking with 'cc
-g -o rec-pascal $(OBJ) -ll', where OBJ is the list of object files. 
The Sun yacc procduced 'y.tab.c' file, when compiled on the Silicon
Graphics machine, runs correctly, which is why I suspect that the
problem is not fundamentally part of yacc... 

What's going on?

Send replies to me, and if there is sufficient interest I'll post a
summary.

__________________________________________________________________________
Colin Brough                           Edinburgh Parallel Computing Centre
cmb at castle.ed.ac.uk                    James Clerk Maxwell Building
cmb%ed.ac.uk at nsfnet-relay.ac.uk        Mayfield Road
                                       Edinburgh  EH9 3JZ
Phone: +44 31-650-5022                 SCOTLAND
Fax:   +44 31-662-4712
__________________________________________________________________________