[splint-discuss] Re: How to tell splint to not pre-define things?

[Grant Edwards]

On Wed, Oct 27, 2004 at 12:51:09PM -0500, Grant Edwards wrote:

>> [Where did those come from?  Splint comlains if I try to define
>> those, yet splint has no way of knowing what they're supposed
>> to be.]
>> 
>>   *1 (Constant)
>>   ^14 23$#__USER_LABEL_PREFIX__#__REGISTER_PREFIX__#__TIME__
>>   ^17 5$#S_SPLINT_S#__LCLINT__#__i686
>> 
>> [OK, I can see where S_SPLINT and __LCLINT__ might need to be
>> defined, but why the rest?  Why is __i686 defined?  My
>> architecture is H8/300H, so defining __i686 is just plain
>> wrong.]
> 
> I tried rebuilding after doing configure --target=h8300-elf,
> but that doesn't seem to make any difference.  Splint still
> predefines __i686 and a bunch of other unwanted stuff.

Doh! I wasn't running the correct splint binary.  Now splint
pre-defines __h8300.  That's still undesirable behavior, but
it's a little less wrong than defining __i686.  The correct
macro to define is either __H8300__ or __H8300H__ depending
on which processor is being used.

Is there some way I can edit a library file to remove the
incorrectly pre-defined stuff, so that I can then load that
library file, and end up with the same set of macros defined
that I do when I compile using gcc?

The other thing I'm going to try is to hack cpplib.c and just
comment out the lines that incorrectly pre-define stuff.

The ones I care about most are the processor type macro and
__SIZE_TYPE__ and __PTRDIFF_TYPE__.  The values of those macros
depend on which processor is being used: __SIZE_TYPE__ could be
either "long unsigned int" or "unsigned int" __PTRDIFF_TYPE__
could be either "long int" or "int".

-- 
Grant Edwards
grante at visi.com