On 11 April 2016 at 16:54, Jeff Morriss <[email protected]> wrote:
> > > On Mon, Apr 11, 2016 at 11:36 AM, Graham Bloice < > [email protected]> wrote: > >> >> >> On 11 April 2016 at 16:03, Jeff Morriss <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Apr 11, 2016 at 10:29 AM, Jeff Morriss < >>> [email protected]> wrote: >>> >>>> >>>> On Sun, Apr 10, 2016 at 4:44 PM, Graham Bloice < >>>> [email protected]> wrote: >>>> >>>>> After creating an initial change to add checkAPI to CMake builds, >>>>> following the current checks done by nmake, I got the attached (massaged) >>>>> output. >>>>> >>>> >>>> >>>>> CUSTOMBUILD : error : Found prohibited APIs in guid-utils.c: >>>>> _snwprintf >>>>> [C:\buildbot\builders\windows-x86-petri-dish\windows-x86-petri-dish\build\cmbuild\epan\checkAPI_epan.vcxproj] >>>>> >>>> >>>> Gerald (in r43756) said this should be StringCchPrintf(). Not sure >>>> why. >>>> >>> >>> The Windows docs say the latter function is safer; change submitted. >>> >>> >>>> CUSTOMBUILD : error : Found prohibited APIs in ftype-guid.c: strncpy >>>>> [C:\buildbot\builders\windows-x86-petri-dish\windows-x86-petri-dish\build\cmbuild\epan\ftypes\checkAPI_ftypes.vcxproj] >>>>> CUSTOMBUILD : error : Found prohibited APIs in ftype-pcre.c: strcpy >>>>> [C:\buildbot\builders\windows-x86-petri-dish\windows-x86-petri-dish\build\cmbuild\epan\ftypes\checkAPI_ftypes.vcxproj] >>>>> CUSTOMBUILD : error : Found prohibited APIs in ftype-string.c: strcpy >>>>> [C:\buildbot\builders\windows-x86-petri-dish\windows-x86-petri-dish\build\cmbuild\epan\ftypes\checkAPI_ftypes.vcxproj] >>>>> CUSTOMBUILD : error : Found prohibited APIs in ftype-time.c: strcpy >>>>> [C:\buildbot\builders\windows-x86-petri-dish\windows-x86-petri-dish\build\cmbuild\epan\ftypes\checkAPI_ftypes.vcxproj] >>>>> >>>> >>>> Looks like these have snuck in while the buildbots weren't running >>>> checkapi; checkapis run from autotools also complains. >>>> >>> >>> Actually, no, those have "always" been there; neither the nmake nor >>> autotools checkapi ran in that directory. >>> >> >> There's a call to the checkapi target in ftypes in the main >> Makefile.nmake and in epan\ftypes\Makefile.nmake there is a checkapi target >> that does call checkAPIs.pl on the NONGENERATED_C_FILES, which from >> epan\ftypes\Makefile.common lists those files found to be at fault. >> > > The first time I looked I just did "make -C epan/ftypes checkapis" which > is what made me think it was a bug. But the code there was ancient so I > looked a bit more and eventually found that it's actually commented out in > the top-level Makefile.{nmake,am}: > > cd ../ftypes > ## $(MAKE) /$(MAKEFLAGS) -f Makefile.nmake checkapi > Well Duh. I looked at that code lots when making the CMake changes and still missed it. So should epan and epan\ftypes be in or out? I suppose I could replicate the commenting out :-( > > I have no idea if the correct directories are being checked, as I said, I >> just followed what nmake did (mostly). >> > > Agreed - just getting us to where we were would be good. > > >> The other issue with CMake and checkAPIs is that CMake doesn't require >> enumerating header files, so there are no lists of files to feed to the >> script. In the plugins I added a file(GLOB *.h) call to create such a list >> of headers for checking but didn't do that generally. I guess there's a >> few spots where it could be useful. >> > > I didn't even know we were checking header files... I guess it makes > sense though. > > -- Graham Bloice
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
