#456 Display config APIs have incorrect padding

[rossy]

The DISPLAYCONFIG_PATH_INFO, DISPLAYCONFIG_PATH_TARGET_INFO and DISPLAYCONFIG_TARGET_DEVICE_NAME structures in wingdi.h seem to have incorrect padding.

In MinGW-w64/GCC:

sizeof(DISPLAYCONFIG_PATH_INFO) = 88
sizeof(DISPLAYCONFIG_PATH_TARGET_INFO) = 56
sizeof(DISPLAYCONFIG_TARGET_DEVICE_NAME) = 424

In the Platform SDK/MSVC++:

sizeof(DISPLAYCONFIG_PATH_INFO) = 72
sizeof(DISPLAYCONFIG_PATH_TARGET_INFO) = 48
sizeof(DISPLAYCONFIG_TARGET_DEVICE_NAME) = 420

I'm fairly sure the other display config structures are correct.

[rossy]

I think this is partially because the definition of the DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY enum is wrong. sizeof(DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY) should be 4, but in MinGW it's 8. I'm not sure how to fix this.

[snarfle]

Well, you can change DISPLAYCONFIG_OUTPUT_TECHNOLOGY_OTHER from -1 to 0xFFFFFFFF. For details, check out the definition of DISPLAYCONFIG_OUTPUT_TECHNOLOGY_FORCE_UINT32 on https://msdn.microsoft.com/en-us/library/windows/hardware/ff554003%28v=vs.85%29.aspx (and hold your nose). Apparently this trick does not work in gcc.

[rossy]

Thanks, that works. I also tried the following, which seems to make the enum work the same as in MSVC++ for casting and sign extension:

typedef enum {
  DISPLAYCONFIG_OUTPUT_TECHNOLOGY_OTHER                 = -1,
  DISPLAYCONFIG_OUTPUT_TECHNOLOGY_INTERNAL              = -2147483647 - 1,
  DISPLAYCONFIG_OUTPUT_TECHNOLOGY_FORCE_UINT32          = 0x7FFFFFFF
} DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY;

It's definitely odd that the docs say the FORCE_UINT32 field is for the benefit of other compilers when it doesn't work in GCC.

[snarfle]

There is also "DISPLAYCONFIG_OUTPUT_TECHNOLOGY_OTHER = (UINT32)-1". I don't know what the "right" fix is here. A change to gcc? Or finding all the enums in mingw-w64 that use -1 and make sure they work right?

[rossy]

Well, I hope this kind of thing isn't common. It looks like a mistake on Microsoft's part to have a "FORCE_UINT32" field on an enum with signed values.

Though my knowledge of C casting rules isn't that good, I think my solution behaves the same as MSVC with regards to the "signedness" of the enum, but it might be better to rectify MS's mistake and make the enum unsigned on mingw-w64.

[snarfle]

There are 8 instances of FORCE_UINT32 in wingdi.h (including DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY). And I see potential problems on RecordCreateOptionsEnum (adoint.h) and tomConstants (tom.h). So, not as big a problem as I feared.

Someone besides me (you?) will need to decide what fix is required.

[Ozkan Sezer]

Kai?

[LRN]

5d61ecd2d087a3a1bdaa9db90270ae0eac121db0 in master should fix this