Bug in Win32file WaitCommEvent ???

[Grant Edwards]

In article <3DDD711D.2000802 at skippinet.com.au>, Mark Hammond wrote:

>> I've verified that the above is correct. I wrote a C program
>> that verifies that the value pointed to by the pointer passed
>> to WaitCommEvent() is written to later: after the event
>> happens.
> 
>:(
> 
> So what do we do?

I was afraid you were going to ask that.  :)

> We can't break backward compatibility.

So whatever we do, the WaitCommEvent call has to return a tuple
of two integers?

Well a quick fix would be to make the mask value static. That
would prevent possible stack corruption, but there'd be no way
to get the delayed mask value after doing overlapped
WaitCommEvents. And, it could break existing apps that do
multiple simultaneous WaitCommEvent() calls.  Probably not a
good idea.

Could we add a field to the Python version of the overlapped
object that could be used as persistent storage for this?  The
overlapped object defines the context for the request.  Or use
one of the fields in the existing in the C OVERLAPPED struct
(maybe Offset?  It's supposedly ignored for communications
devices -- though using it for some other purpose is asking for
trouble).

> I guess we may need a new function that manages a little 4-byte
> buffer for this value.

I guess, but I don't know how that would work without breaking
backwards compatibility.

> Suggestions welcome.  Obviously, code even more so <wink>

Oy.  I barely know C++, and don't have much of an idea how the
whole library-wrapping scheme works.  Can the Win32 extensions
be built with Borland C?

-- 
Grant Edwards                   grante             Yow!  .. If I had heart
                                  at               failure right now,
                               visi.com            I couldn't be a more
                                                   fortunate man!!