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)
To: eric@rrinc.com
Cc: lclint-interest@larch.lcs.mit.edu
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) ()
	# endif

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.)

--- Dave