Wireshark-dev: Re: [Wireshark-dev] checkapi
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Tue, 19 Apr 2016 22:29:40 -0400
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...