libpcap icon indicating copy to clipboard operation
libpcap copied to clipboard

Errors when updating the Npcap SDK from 1.12 to 1.13

Open fxlb opened this issue 3 years ago • 5 comments

C:/projects/libpcap/Win32/npcap-sdk-1.13/Include/Packet32.h:422:29: error: unknown type name '_Post_invalid_'
  VOID PacketFreePacket(_In_ _Post_invalid_ LPPACKET lpPacket);
                             ^~~~~~~~~~~~~~
[...]
C:/projects/libpcap/Win32/npcap-sdk-1.13/Include/Packet32.h:434:31: error: unknown type name '_Post_invalid_'
  VOID PacketCloseAdapter(_In_ _Post_invalid_ LPADAPTER lpAdapter);
                               ^~~~~~~~~~~~~~

(See https://ci.appveyor.com/project/guyharris/libpcap/builds/44291195/job/xcujd0uqm4nbox74) (After ea4a55ad9be0e05d21e079056242c32dd3528dbe)

fxlb avatar Jul 27 '22 08:07 fxlb

This is the result of adding SAL annotations to Npcap's Packet32.h in nmap/npcap@a22a54788a7cb8ad6ba984a076316f9961018e22. Visual Studio should be able to handle them, but it appears that MinGW-w32 can't.

If this is due to header files that you're supposed to include for SAL annotations, but that you can get away with not including with Visual Studio (perhaps because some VS header file includes them for you) but can't get away with with MinGW-w32, that means that Npcap should probably be changed to fix that (because other code using Packet32.h might also fail to compile on MinGW-w32).

If, however, it's just because none of the versions of MinGW-w32 supported on AppVeyor support SAL annotations at all, then either 1) we need to get rid of the MinGW-w32 builds until AppVeyor supports a newer version that does support SAL annotations (if one exists) or 2) we should try to get Windows builds working on Cirrus CI if that can be made to support a newer version of MinGW-w64 that supports SAL annotations (if one exists).

If none exists, we just kick MinGW-w64 builds with Npcap to the curb.

Note that MinGW-w64 produces a pile of other annoying warnings, such as complaints about "%z[doux]" formats (sounds like either a tired old compiler or a compiler that's expecting a tired old printf implementation), so either a newer version might be a good idea, or we need to figure out how to make the code not produce all those warnings.

(And switching to Cirrus CI for Windows might make fewer builds fail, if Cirrus CI doesn't get as many failures to connect to remove servers to download software as AppVeyor does.)

I've removed all the MinGW-w64 builds for now; I'll put back the WinPcap SDK build, so we at least get some of the annoying pile-of-warnings.

@gvanem, any suggestions?

guyharris avatar Jul 27 '22 09:07 guyharris

A:

#ifndef _Post_invalid_ 
#define _Post_invalid_    
#endif

somewhere.

gvanem avatar Jul 27 '22 09:07 gvanem

Or just include sal.h in Packet32.h.

That may break builds with older versions of MinGW-w32 without sal.h - or, rather, make the problem more obvious, by failing to include sal.h rather than failing with some build error later on; if fixing that is deemed worth the effort, I guess we could test the version of MinGW-w32, if that's #defined somewhere, and, if it's too old, add the relevant #defines instead of including sal.h.

(I'm not sure why _In_ isn't causing a problem.)

In any case. I've filed nmap/npcap#617 against Npcap, to have Packet32.h include sal.h.

guyharris avatar Jul 27 '22 11:07 guyharris

The fix is in npcap-1.72.zip, but the latest SDK archive is still npcap-sdk-1.13.zip, so it will take some time to confirm this issue has been completely resolved.

infrastation avatar Dec 29 '22 01:12 infrastation