Re: checkapi

[Graham Bloice <graham.bloice () trihedral com>]

On 20 April 2016 at 03:29, Jeff Morriss <jeff.morriss.ws () gmail com> wrote:

> On 04/19/2016 05:17 AM, Graham Bloice wrote:
>
> > On 18 April 2016 at 22:48, Guy Harris <guy () alum mit edu
> > <mailto:guy () alum mit edu>> wrote:
> >
> >     On Apr 18, 2016, at 2:16 PM, Graham Bloice
> >     <graham.bloice () trihedral com <mailto:graham.bloice () trihedral com>>
> >     wrote:
> >
> >     > What should we do about the lex files?  Guy's last comment on this
> > issue was
> >     >
> >     > Some "generated" code is "generated" by copying it from the
> > .l/.lemon/.y/etc. files; the problem is that we'd like to check that code,
> > but not code that's actually *generated*.
> >
> >     Can we make checkapi.pl <http://checkapi.pl> capable of reading .l
> >     and .y files?  If so, we should process them, not the generated files.
> >
> >     (Lemon is less important, as we have our own fork of Lemon and can
> >     change it, although we may not want to make Wireshark-specific
> >     changes, so it might also be useful to have checkapi.pl
> >     <http://checkapi.pl> capable of processing them as well.)
> >
> >
> > checkAPIs.pl appears to be able to parse .l files at present, hence the
> > errors I noted in my previous email.
> >
> > FWIW, the nmake implementation also passed .l files to checkAPIs.pl.
> > The change (14873) currently in progress also passes .lemon .and .y
> > files (as did nmake) to the script but there are either no errors
> > reported, or the script silently fails on them.
>
> The malloc() in those .l files appears to be there to silence
> unused-parameter warnings.
>
> checkAPIs arguably should be updated to have a
> configuration-file-per-directory kind of thing where we can put exclusions
> (like "don't worry about malloc calls in .l files") but until then I'd say
> just skip the files.  The code in the .l files is such a tiny portion of
> our code base anyway...
The latest update to the change no longer checks .l files, so no errors are
produced now, just warnings.

This leaves one last issue, the command line for the checkAPIs call in
epan\dissectors is too long for a Visual Studio solution \ msbuild which
unhelpfully drops a single character at (I think) 8192 byte intervals.
This leads to erroneous file names being passed into checkAPIs and output
such as:

  No such file: "paket-h261.c" at
C:/buildbot/builders/windows-x86-petri-dish/windows-x86-petri-dish/build/tools/checkAPIs.pl
line 2034.
  No such file: "packet-siulcrypt.c" at
C:/buildbot/builders/windows-x86-petri-dish/windows-x86-petri-dish/build/tools/checkAPIs.pl
line 2034.
  No such file: "packet-h25.h" at
C:/buildbot/builders/windows-x86-petri-dish/windows-x86-petri-dish/build/tools/checkAPIs.pl
line 2034.

It's not easy in CMake to split the lists into smaller chunks (unless
someone know the magic incantations) so I think the best solution is to get
CMake to generate a file and modify checkAPIs.pl to take a filename
parameter as the list of files to check.

There is also the issue that the check is run in the source tree, so
generated files that are created in the build tree (for out-of-tree builds)
are also not found by checkAPIs.pl:

  No such file: "packet-ncp2222.c" at
C:/buildbot/builders/windows-x86-petri-dish/windows-x86-petri-dish/build/tools/checkAPIs.pl
line 2034.
  No such file: "register.c" at
C:/buildbot/builders/windows-x86-petri-dish/windows-x86-petri-dish/build/tools/checkAPIs.pl
line 2034.

So, I'm looking for a Perl wrangler to add two features to checkAPIs.pl:

   1. Add a parameter that takes a filename and is used as the source of
   files to check.
   2. Add a parameter that takes a path and is used as an additional path
   to prefix on to a filename when attempting to open a file for parsing.

For (1) the format of the file should be specified, I'm not certain yet
what's easiest to produce from CMake.

Other solutions to these issues are welcome.

-- 
Graham Bloice

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe