winapi_test chokes on TITLEBARINFO

[Francois Gouget]

When I run ./tools/winapi/winapi_test it chokes on the TITLEBARINFO
declaration in winuser.h:

typedef struct tagTITLEBARINFO {
    DWORD cbSize;
    RECT  rcTitleBar;
    DWORD rgstate[CCHILDREN_TITLEBAR+1];
} TITLEBARINFO, *PTITLEBARINFO, *LPTITLEBARINFO;

include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type
('DWORD') ('CCHILDREN_TITLEBAR+1')
Can't use string ("4") as a SCALAR ref while "strict refs" in use at
tools/winapi/c_type.pm line 283.

I believe this is because it does not know how to compute the value of
'CCHILDREN_TITLEBAR+1'. Though I'm not sure the second error is really
related to the first one.

I had a look but I'm pretty lost in the winapi code. Does anyone know
how to fix this problem?

[Hans Leidekker]

On Tuesday 20 January 2004 14:09, Francois Gouget wrote:
> include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type
> ('DWORD') ('CCHILDREN_TITLEBAR+1')
> Can't use string ("4") as a SCALAR ref while "strict refs" in use at
> tools/winapi/c_type.pm line 283.

That code is mixing up the use of a variable holding a string
and a variable holding a reference. Put otherwise it forget's
to dereference a scalar ref (similar to a C pointer variable)
before using it. Patch below fixes it.

-Hans

Changelog:
  Fix misuse of scalar reference variable.

[Francois Gouget]

On Tue, 20 Jan 2004, Hans Leidekker wrote:
> On Tuesday 20 January 2004 14:09, Francois Gouget wrote:
> > include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type
> > ('DWORD') ('CCHILDREN_TITLEBAR+1')
> > Can't use string ("4") as a SCALAR ref while "strict refs" in use at
> > tools/winapi/c_type.pm line 283.
>
> That code is mixing up the use of a variable holding a string
> and a variable holding a reference. Put otherwise it forget's
> to dereference a scalar ref (similar to a C pointer variable)
> before using it. Patch below fixes it.

Yep, fixed the problem here. Thanks!

[Francois Gouget]

On Tue, 20 Jan 2004, Hans Leidekker wrote:
[...]
> That code is mixing up the use of a variable holding a string
> and a variable holding a reference. Put otherwise it forget's
> to dereference a scalar ref (similar to a C pointer variable)
> before using it. Patch below fixes it.

Arg. Spoke a bit too quick in my previous email. This patch introduces a
new problem. When verifying the generated.c files I see a lot of diffs
of the form:

-    TEST_FIELD(BITMAPINFO, RGBQUAD[1], bmiColors, 40, 4, 1);
+    TEST_FIELD(BITMAPINFO, RGBQUAD[1], bmiColors, 40, 4, SCALAR(0x844a5c8));

So it looks like something is not deferenced right somewhere...
I'm still as lost as before. Do you know where the bug is?

[Hans Leidekker]

On Tuesday 20 January 2004 11:02, Francois Gouget wrote:
> Arg. Spoke a bit too quick in my previous email. This patch introduces a
> new problem. When verifying the generated.c files I see a lot of diffs

Well, it merely uncovers two more cases of reference variable
misuse. Revised patch attached.

-Hans