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

Siddhesh Poyarekar siddhesh@redhat.com
Mon Jun 11 12:53:00 GMT 2012


On Fri, 8 Jun 2012 17:27:35 +0200, Jan wrote:
> On Fri, 08 Jun 2012 16:16:36 +0200, Jan Kratochvil wrote:
> > Wrote the attached script and the "diff" has now "just" 7375
> > lines.  This seems to be reviewable.
> 
> Fixed there some whitespacing issues, therefore:
> 
> 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 -Isplint -exportlocal -DTUI -I. -Icommon -I../include
> -I../bfd -I../libdecnumber -I../opcodes -I.. -I/usr/include/python2.7
> $i &>splint/$i.out;done appropriately mv splint splint-clean and mv
> splint splint-bitpos find splint-clean/  -type f|sort|xargs cat|perl
> -lpe 's/^(\s*)(\S*?\.[ch]:\d+:\d+):/$1LOC $2\n/' >splint-clean.out
> find splint-bitpos/ -type f|sort|xargs cat|perl -lpe
> 's/^(\s*)(\S*?\.[ch]:\d+:\d+):/$1LOC $2\n/' >splint-bitpos.out
> locdiff splint-clean.out splint-bitpos.out 
> 
> http://people.redhat.com/jkratoch/locdiff.out
> 

Thanks, I'm building on your idea to make the list even smaller.
So far, adding '-hints -showcolumn -linelen 999' to the splint
commandline and then adjusting the above regex to remove the additional
\d+: has forced all outputs to be cleaner and in one-line per warning,
so we can expect output of the type:

 LOC <location>
- <old>
- <new>

in a lot of cases. This has reduced the output to about 4.2k, mostly
due to the reduced wrapping. I am now working on using this to eliminate
the following warnings:

* Warnings about the argument 2 of extract_unsigned_integer having to
  be int. This is the size of a primitive and is hence always safe.
* Earlier warning was assignment from int to unsigned int (or
  vice-versa) and that has now changed from LONGEST to ULONGEST.

These form a fairly large part of the outputs, so I hope to make the
final list to review much smaller than what we currently have. Please
let me know if any of the above assumptions or wrong or if there are
any other cases I can eliminate.

Thanks,
Siddhesh



More information about the Gdb-patches mailing list