Can #undef interface cause problems with Windows ports?

[ndim]

Describe the bug Commit 4ae3e2655fc8cddf9fba17a2689b4a97279ac31e (2014-02-22 Marcus Meissner) introduces the#undef interface after the #include <windows.h> because apparently windows.h defines interface for something windows specific, but libgphoto2_port uses int interface; definitions in a few places:

https://github.com/gphoto/libgphoto2/blob/731909b865848c2d5bc79cdf3f560d0284287061/libgphoto2_port/libusb1/libusb1.c#L141 https://github.com/gphoto/libgphoto2/blob/731909b865848c2d5bc79cdf3f560d0284287061/libgphoto2_port/gphoto2/gphoto2-port.h#L83

Now that people are actually working on making libgphoto2 work on Windows, the question arises: Can the #undef interface cause actual problems with a Windows port of libgphoto2, and any C compilation units eventually including libgphoto2_port/gphoto2/gphoto2-port-portability.h? What is the interface macro actually supposed to do?

Name the camera N/A

libgphoto2 and gphoto2 version libgphoto2 2.5.4 to at least 2.5.27.1 (according to the git history)

[msmeissn]

If I remember correctly think it was eithre a C++ or MIDL artifact from windows headers.

i think it okay to undef after windows includes.

[msmeissn]

so i would say: No

[manongjohn]

I've compiled versions 2.5.16 and later in MSCV 2019 and still run into issues with int interface; when I try to integrate it into my application. I added this to gphoto2-port.h as a workaround for myself:

ifdef interface

undef interface

define _RESTORE_INTERFACE

endif

typedef struct _GPPortSettingsUSB {
......
int interface;      /**< \brief USB Interface number used. */
......
} GPPortSettingsUSB;

ifdef _RESTORE_INTERFACE

define interface STRUCT

undef _RESTORE_INTERFACE

endif

I never had to do anything to libusb1.c