Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!nosc!humu!uhccux!lee
From: lee@uhccux.uhcc.hawaii.edu (Greg Lee)
Newsgroups: comp.sys.atari.st
Subject: Re: Sozobon C C
Message-ID: <3207@uhccux.uhcc.hawaii.edu>
Date: 5 Feb 89 23:11:31 GMT
References: <608@nikhefh.hep.nl>
Organization: University of Hawaii
Lines: 37

From article <608@nikhefh.hep.nl>, by n62@nikhefh.hep.nl (Klamer Schutte):
"In article <7302@batcomputer.tn.cornell.edu> wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) writes:
">I recently unloaded Sozobon C sources from the net. I'm trying
">to get them to work as cross compilers in a couple of environments.
"so have i, on a sun.
">1) No version will self compile without errors: The message
">is usually "Weird ......."
"
"I did not get such a kind of error, the only change i had to make was to make 
"the program believe the compiler ( (i think normal) cc on sun/3 ) did not 
"support enum; Where is the bug? I never have used enum. Please somebody answer.

I'm trying to get it to work on Ultrix 2.2.  pcc will not accept the
code with ENUMS defined, but it will without.  gcc (v. 1.31) will
compile it with ENUMS defined.  However with both I encounter a
bug involving bit-fields.  Maybe someone has a suggestion.  The
code generation routines in gen.c get the idea that stuff inside
a struct is a bit-field with field-width (g_fldw) equal to the
entire size of the struct.  Even though no bit fields have been
declared.  The consequence is that code for accessing a bit-field
is generated, and ultimately an error.

The following causes the error (with the declarations of node.h):

char *xxx;
NODE *tp;
	xxx = tp->e_name;

The error can be prevented by commenting out the following lines
in routine 'u_sube' (file 'gen.c'):

		if (np->g_fldw)
			return fldget(np, flags);

but then the correct code for bit-fields is not generated.

		Greg, lee@uhccux.uhcc.hawaii.edu