[Mingw-notify] [ mingw-Bugs-2121748 ] w32api-3.12:vfw.h: usage of WM_CAP_FIRST[AW] is invalid

[SourceForge.net <no...@so...>]

Bugs item #2121748, was opened at 2008-09-21 09:59
Message generated for change (Settings changed) made by ir0nh34d
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2121748&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: SquallATF (squallatf)
Assigned to: Chris Sutcliffe (ir0nh34d)
Summary: w32api-3.12:vfw.h: usage of WM_CAP_FIRST[AW] is invalid

Initial Comment:
at line 1203 and 1204
undefined WM_CAP_FIRSTA and WM_CAP_FIRSTW
the compiler will report error: 'WM_CAP_FIRSTA' undeclared (first use in this function)

----------------------------------------------------------------------

Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2008-09-24 10:23

Message:
Thanx for the explanation, I had assumed that the preprocessor would
resolve WM_CAP_FIRST[A/W] prior to defining the other constants.

Given how things works, as you pointed out, there seems to be 2 solutions,
don't undef WM_CAP_FIRST[A/W] or change them the other contants to use the
'resolved' values for WM_CAP_FIRST[A/W] (i.e. WM_USER or WM_USER+100). 
Removing the undef is easier, but it leaves WM_CAP_FIRST[A/W] defined, is
this an issue?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-23 11:57

Message:
> According to MSDN WM_CAP_FIRST[A/W] is not defined.  In the
> header it appears that it's defined to assist in defining the
> messages types in the block between 1137 and 1201.  Is it
> necessarily an error to undef it after it's served it's
> purpose?

It wouldn't be, if it really had served its purpose, but in this case, it
hasn't served *any* purpose by the time it's #undefd.  Let's consider just
one example:--

  #define WM_CAP_FIRSTA                   (WM_USER)
  #define WM_CAP_FIRSTW                   (WM_USER + 100)

  #define WM_CAP_SET_CALLBACK_ERRORA      (WM_CAP_FIRSTA + 2)
  #define WM_CAP_SET_CALLBACK_ERRORW      (WM_CAP_FIRSTW + 2)

At this point, WM_CAP_FIRSTA is #defined, (literally), as (WM_USER), and
WM_CAP_FIRSTW is, (also literally) (WM_USER + 100): note that the
preprocessor makes no attempt to resolve this to any more primitive state,
in the context of the #define statement.  Thus, by analogy,
WM_CAP_SET_CALLBACK_ERROR[AW] also retain literal references to
WM_CAP_FIRST[AW] respectively, but...

  #undef WM_CAP_FIRSTA
  #undef WM_CAP_FIRSTW

...here you destroy the definitions of WM_CAP_FIRST[AW], so...

  #ifdef UNICODE
  #define WM_CAP_SET_CALLBACK_ERROR       WM_CAP_SET_CALLBACK_ERRORW
  ...

  #else
  #define WM_CAP_SET_CALLBACK_ERROR       WM_CAP_SET_CALLBACK_ERRORA

...when the user subsequently refers to WM_CAP_SET_CALLBACK_ERROR, the
preprocessor will expand that recursively to say, for the ASCII case...

  WM_CAP_SET_CALLBACK_ERROR --> WM_CAP_SET_CALLBACK_ERRORA
  WM_CAP_SET_CALLBACK_ERRORA --> (WM_CAP_FIRSTA + 2)

...and here is where it breaks, because at this point WM_CAP_FIRSTA is no
longer #defined; therefore the intended next level of recursion...

  (WM_CAP_FIRSTA + 2) --> ((WM_USER) + 2)

...*doesn't* occur, and you are left with an apparent reference to an
undeclared variable called WM_CAP_FIRSTA.


----------------------------------------------------------------------

Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2008-09-22 16:16

Message:
According to MSDN WM_CAP_FIRST[A/W] is not defined.  In the header it
appears that it's defined to assist in defining the messages types in the
block between 1137 and 1201.  Is it necessarily an error to undef it after
it's served it's purpose?

I have no issue deleting the offending lines, but my assumption is that
they were added so as to not cause any possible collisions should someone
want to define WM_CAP_FIRST[A/W] for their own purposes.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-22 11:59

Message:
Firstly, this was incorrectly reported as a mingwrt-3.15 issue; it is a
w32api-3.12 issue.

Indeed, the pair of `#undef's at lines 1203 and 1204 invalidate the entire
block of `#define's appearing between lines 1137 and 1201 inclusively; at
point-of-use, each of these `#define's requires that one or other of
WM_CAP_FIRSTA or WM_CAP_FIRSTW remains as `#define'd on line 1134 or 1135
respectively.  By inference, this also invalidates the block of generic
`#define's appearing between lines 1206 and 1232.

Similarly, the `#undef capSendMessage' on line 1292 invalidates the block
of `#define's appearing between lines 1236 and 1290.

The obvious solution would seem to be to simply delete the three `#undef'
statements.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2121748&group_id=2435