Package: mingw-w64-common
Version: 5.0.1-1

The following trivial souce file fails to compile with MinGW:

------
#include <windows.h>
#define COMPILE_MULTIMON_STUBS
#include <multimon.h>
------

with the following errors:

$ x86_64-w64-mingw32-gcc -c mingtest.c
In file included from mingtest.c:3:0:
/usr/share/mingw-w64/include/multimon.h: In function  IsPlatformNT :
/usr/share/mingw-w64/include/multimon.h:130:38: error:  osvi  undeclared (first 
use in this function)
     oi.dwOSVersionInfoSize = sizeof (osvi);
                                      ^
/usr/share/mingw-w64/include/multimon.h:130:38: note: each undeclared 
identifier is reported only once for each function it appears in
In file included from mingtest.c:3:0:
/usr/share/mingw-w64/include/multimon.h: In function  xGetMonitorInfo :
/usr/share/mingw-w64/include/multimon.h:260:16: error: invalid type argument of 
 ->  (have  MONITORINFOEX {aka struct tagMONITORINFOEXA} )
  lstrcpyn (c.ex->szDevice, "DISPLAY", sizeof (c.ex->szDevice));
                ^
/usr/share/mingw-w64/include/multimon.h:260:51: error: invalid type argument of 
 ->  (have  MONITORINFOEX {aka struct tagMONITORINFOEXA} )
  lstrcpyn (c.ex->szDevice, "DISPLAY", sizeof (c.ex->szDevice));
                                                   ^

It looks as if this header file has never been tested at all in the mode
that uses COMPILE_MULTIMON_STUBS.

The first line should simply use the actual variable name 'oi' in place
of the nonexistent one 'osvi'. (The point is that this is one of the
many Windows API structs whose first element is a field giving its own
size, to permit later API revisions to append fields to the end without
overrunning memory in older clients, so it's clear that the sizeof is
meant to apply to the _same_ structure we're writing into.)

The second pair of errors arise because c.ex is an actual MONITORINFOEX
structure rather than a pointer to one. So candidate fixes are to
replace the '->' with '.', or to make c.ex a pointer. Looking at the
code, the latter seems like the right choice, because the point of 'c'
itself seems to be that it's a union used to type-pun between pointers
to two related structure types; the user passes in a pointer to
MONITORINFO, and we turn it into a pointer to MONITORINFOEX (which
includes an extra field at the end), and then write the extra field if
the size field permits. So both members of 'c' ought to be pointers, and
hence the right fix is to declare the union at the top of
xGetMonitorInfo() so that the field 'ex' has type LPMONITORINFOEX rather
than plain MONITORINFOEX.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <ana...@pobox.com>

Reply via email to