[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 20 April 2016 at 03:29, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

On 04/19/2016 05:17 AM, Graham Bloice wrote:

On 18 April 2016 at 22:48, Guy Harris <guy@xxxxxxxxxxxx
<mailto:guy@xxxxxxxxxxxx>> wrote:

    On Apr 18, 2016, at 2:16 PM, Graham Bloice
    <graham.bloice@xxxxxxxxxxxxx <mailto:graham.bloice@xxxxxxxxxxxxx>>
    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