lclint-interest message 58
From evs Fri Mar 22 13:12:32 1996
Date: Fri, 22 Mar 96 12:49:12 -0500
From: evs (David Evans)
In-Reply-To: Eric Bloodworth's message of Fri, 22 Mar 1996 12:06:08 -0500 <3152DE00.4DAA@rrinc.com>
Subject: problems with lclint, gcc, unixware
> 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).
I'm not sure quite what you mean here. You can use the -I flag to
select the header directories search by lclint, just as you would do for
a C compiler. This can be set in your ~/.lclintrc file so you don't
have to set it at the command line every time.
> My questions are,
> why doesn't lclint use gcc to do the preprocessing and was this
> the "right" way to handle this problem?
If you want to use gcc -E, set the LCLINT_CPPCMD environment variable to
"gcc -E". Depending on how the Makefile was configured when you build
lclint, the default c pre-processor was set to /lib/cpp. LCLint is
meant to be as platform independent as possible, and believe it or not,
not everyone has gcc, so /lib/cpp is the default.
> 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) ()
to at least hide the syntax problems. Unfortunately, this doesn't work
for gcc's __asm__.
The other problem with trying to support extension like this is that
unless you are very careful, you risk breaking perfectly good ANSI
programs designed for a compiler that doesn't support these conventions
(e.g., if I made asm a keyword and supported special syntax, standard
ANSI programs that use asm as an identifier would break.)
University of Virginia, Computer Science