Re: [PATCH v3] Expand bitpos and type.length to LONGEST and ULONGEST

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Mon, 11 Jun 2012 14:59:33 +0200, Jan wrote:
> > Please let me know if any of the above assumptions or wrong or if
> > there are any other cases I can eliminate.
> 
> I agree with these assumptions.
> 
> 

Here's where I'm at right now. I modified the splint command to look
like the following:

rm -rf splint/
mkdir -p splint/bits
touch splint/bits/confname.h
for i in `cat files`; do
	mkdir -p splint/`dirname $i`
	splint +posixlib +gnuextensions -linelen 999 -hints -showcolumn
\ -Isplint -exportlocal -DTUI -I. \
		-Icommon -I../include -I../bfd -I../libdecnumber
-I../opcodes \ -I.. -I/usr/include/python2.7 $i &>splint/$i.out
done

and used the rest of the commands as is:

	find splint-clean/  -type f|sort|xargs cat|perl -lpe
	's/^(\s*)(\S*?\.[ch]:\d+):/$1LOC $2\n/' >splint-clean.out find
	splint-bitpos/ -type f|sort|xargs cat|perl -lpe
	's/^(\s*)(\S*?\.[ch]:\d+):/$1LOC $2\n/'
	>splint-bitpos.out ./locdiff splint-clean.out splint-bitpos.out 

Once I got the locdiff.out, the major improvement was that each warning
has a specific pattern as I mentioned above, which meant that I could
do some further processing to eliminate some of the more obvious
spurious warnings. It also had the effect of reducing the output size
to about 4200 lines.

Then I wrote a script (attached) to reduce this further based on the
following rules:

1) The store_unsigned_integer, extract_unsigned_integer and other
related functions can always safely accept int as argument 2 since the
type length to be passed in it must be a primitive integral type. So we
can ignore all entries that look like:

 LOC
- Function store_unsigned_integer expects arg 2 to be int...
+ Function store_unsigned_integer expects arg 2 to be int...

1) Lines of the following format:
 LOC <details>
-<old>
+<new>

for type incompatibilities are processed to get the old warning and
new warning and then deduce if we have caused a regression due to the
change. The deducion is based on the type assignment warnings before
and after. The basic rule to deduce safety of the change is to ensure
that the target of the assignment is large enough for the source after
the change.

After running this script the changes to review have come to approx
2500 lines (also attached). Does this look OK? If it does, then I can do
a step-by-step review of these changes and post them.

Regards,
Siddhesh

Attachment: process-locdiff
Description: Binary data

Attachment: differ
Description: Binary data