Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Tom Tromey <tromey@redhat.com>
Subject: Re: [PATCH v3] Expand bitpos and type.length to LONGEST and ULONGEST
Date: Mon, 11 Jun 2012 12:53:00 -0000	[thread overview]
Message-ID: <20120611182346.1b8d872b@spoyarek> (raw)
In-Reply-To: <20120608152735.GA26491@host2.jankratochvil.net>

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


  reply	other threads:[~2012-06-11 12:53 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-20 14:53 [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct Siddhesh Poyarekar
2012-02-21 20:46 ` Tom Tromey
2012-02-22  7:44   ` Siddhesh Poyarekar
2012-02-29 13:55   ` Siddhesh Poyarekar
2012-02-29 13:59     ` Siddhesh Poyarekar
2012-03-01 22:45     ` Jan Kratochvil
2012-03-05  6:34       ` Siddhesh Poyarekar
2012-03-05  8:05         ` Jan Kratochvil
2012-03-21 10:06           ` [PATCH] Allow 64-bit enum values Siddhesh Poyarekar
2012-03-27 17:00             ` Jan Kratochvil
2012-03-28  4:19               ` Siddhesh Poyarekar
2012-03-30 16:15                 ` Jan Kratochvil
2012-04-17 14:01                   ` Jan Kratochvil
2012-04-18  2:53                     ` Siddhesh Poyarekar
2012-04-18  6:58                       ` [commit] " Jan Kratochvil
2012-04-18  7:06                         ` [ChangeLog commit] " Jan Kratochvil
2012-04-19 16:58                         ` [commit] " Ulrich Weigand
2012-04-20  4:23                           ` Siddhesh Poyarekar
2012-04-20  7:50                             ` [obv] Fix python-2.4 compilation compat. [Re: [commit] [PATCH] Allow 64-bit enum values] Jan Kratochvil
2012-04-20 19:00                               ` Tom Tromey
2012-03-28 16:55             ` [PATCH] Allow 64-bit enum values Tom Tromey
2012-03-29 10:56               ` Siddhesh Poyarekar
2012-04-17 13:11             ` [commit] Support 64-bit constants/enums on 32-bit host [Re: [PATCH] Allow 64-bit enum values] Jan Kratochvil
2012-04-17 13:16               ` [patch!] " Jan Kratochvil
2012-04-17 14:33               ` [commit] " Tom Tromey
2012-04-17 14:55                 ` Jan Kratochvil
2012-04-17 15:18                   ` Tom Tromey
2012-04-17 15:32                     ` Jan Kratochvil
2012-04-17 19:32                 ` Jan Kratochvil
2012-04-17 20:51                   ` Tom Tromey
2012-04-18  7:01                     ` [real commit] " Jan Kratochvil
2012-04-17 14:33               ` [patch] " Jan Kratochvil
2012-04-17 15:59                 ` Tom Tromey
2012-04-17 15:42                   ` Jan Kratochvil
2012-04-17 15:52                     ` Tom Tromey
2012-02-21 21:39 ` [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct Jan Kratochvil
2012-05-04 13:10   ` [PATCH v2] Expand bitpos and type.length to LONGEST and ULONGEST Siddhesh Poyarekar
2012-05-15  9:46     ` ping: " Siddhesh Poyarekar
2012-05-15  9:49       ` Jan Kratochvil
2012-05-15 10:02         ` Siddhesh Poyarekar
2012-05-15 20:07     ` Jan Kratochvil
2012-05-16  3:50       ` Siddhesh Poyarekar
2012-05-16  7:19         ` Jan Kratochvil
2012-05-16  7:41           ` Siddhesh Poyarekar
2012-05-20 15:43             ` Doug Evans
2012-05-20 20:24               ` Jan Kratochvil
2012-05-20 20:28                 ` Doug Evans
2012-05-23 13:52       ` Siddhesh Poyarekar
2012-05-23 17:46         ` Jan Kratochvil
2012-05-24  1:36           ` Siddhesh Poyarekar
2012-05-24 15:01             ` Jan Kratochvil
2012-05-31 18:15               ` [PATCH v3] " Siddhesh Poyarekar
2012-06-05 22:27                 ` Jan Kratochvil
2012-06-06 18:23                   ` Siddhesh Poyarekar
2012-06-06 21:34                     ` Jan Kratochvil
2012-06-08 14:16                       ` Jan Kratochvil
2012-06-08 15:27                         ` Jan Kratochvil
2012-06-11 12:53                           ` Siddhesh Poyarekar [this message]
2012-06-11 13:00                             ` Jan Kratochvil
2012-06-11 18:33                               ` Siddhesh Poyarekar
2012-06-12  9:56                                 ` Jan Kratochvil
2012-06-12 14:35                                   ` Jan Kratochvil
2012-06-18 10:31                                     ` [1/2][PATCH " Siddhesh Poyarekar
2012-06-20 15:47                                       ` Jan Kratochvil
2012-06-20 16:32                                         ` Siddhesh Poyarekar
2012-06-20 17:25                                           ` Jan Kratochvil
2012-06-23  1:59                                         ` Siddhesh Poyarekar
2012-06-18 10:31                                     ` [2/2][PATCH " Siddhesh Poyarekar
2012-05-31  6:39           ` [PATCH v2] " Siddhesh Poyarekar
2012-05-31  9:24             ` Siddhesh Poyarekar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120611182346.1b8d872b@spoyarek \
    --to=siddhesh@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox