lclint-interest message 59
From firstname.lastname@example.org Fri Mar 22 16:06:38 1996
Date: Fri, 22 Mar 1996 14:19:12 -0500
From: Eric Bloodworth
Organization: Recognition Research, Inc
X-Mailer: Mozilla 2.0 (X11; I; AIX 2)
To: David Evans
Subject: Re: problems with lclint, gcc, unixware (solaris too)
Content-Type: text/plain; charset=us-ascii
David Evans wrote:
> > 1. lclint seems to look in /usr/include for its headers files.
> > Since gcc supplies its own system header files elsewhere, this
> > leads to parsing errors and other troubles. I frankly don't
> > understand why lclint doesn't use gcc to do its preprocessing, but
> > I dutifully set BASEPATH and DEFAULT_SYSTEMDIR in constants.h and
> > SYSTEM_LIBDIR in Makefile to the location of gcc's header files.
> > This seems to cure the problem, but it will require the update of a symlink
> > for every new release of gcc we install (small maintenance headache).
[deleted - stuff I alreay knew :)]
> > 2. lclint barfs (unrecoverable parse error) on gcc's __asm__ statement.
> > Unfortunately, this is used in an inline function in one of
> > gcc's header files (sys/byteorder.h). I'm loath to
> > change gcc's header files because of the maintenance headache,
> > so we managed to keep that file from being included for now.
> > Is there a way to get lclint to understand __asm__? If not,
> > I hereby request this feature for the next release. :-)
> I'm reluctant to start adding complier-specific syntax to lclint, and
> there doesn't appear to be any real consensus as to the syntax for
> including assembly in C programs. The hope is that most compiler's that
> add language extensions will do so in a way that they can be hidden by a
> macro definition, and you could do something like,
> # ifdef __LCLINT__
> # define asm(x) ()
> # endif
> to at least hide the syntax problems. Unfortunately, this doesn't work
> for gcc's __asm__.
[deleted - point taken]
> --- Dave
OK, let me be more specific. I'm now trying this on a solaris machine with the same
1. the makefile _is_ setting gcc -E. configure set it this way.
2. using the -I setting just changes the location of the parse error from the system
includes to gcc's includes. It's in .
3. I ran truss on lclint's processing of a file with a single line: #include
What appears to happen is lclint pre-preprocesses (!) the source file using the headers
in /usr/include, stores a temporary file, it then runs gcc -E on the temporary file, which
of course, uses gcc's header files.
4. When I set BASEPATH and DEFAULT_SYSTEMDIR in constants.h and SYSTEM_LIBDIR in the Makefile
to gnu's directories, the problem goes away.
My conclusion is that lclint assumes that system header files are in /usr/include for this
pre-preprocess step. This isn't a good assumption, IMHO. Why does it need to
side-step gcc -E?
- defining __asm__ as nothing seems to work, or we can patch gcc's header file for i86
machines, I guess.
University of Virginia, Computer Science