win32utils devel - Aug 2009 - [Fwd: Re: FW: win32-api, unsigned long vs long in api_call]

Moving this conversation over to win32utils-devel...
-------------- next part --------------
An embedded message was scrubbed...
From: Heesob Park <phasis at gmail.com>
Subject: Re: FW: win32-api, unsigned long vs long in api_call
Date: Sat, 22 Aug 2009 09:54:05 +0900
Size: 2777
URL:
<http://rubyforge.org/pipermail/win32utils-devel/attachments/20090821/3853fc85/attachment.eml>

On Fri, Aug 21, 2009 at 7:02 PM, Daniel Berger<djberg96 at gmail.com>
wrote:
> Moving this conversation over to win32utils-devel...
>
> Hi,
>
> 2009/8/22 Daniel Berger <djberg96 at gmail.com>:
>> Hi,
>>
>> <snip>
>>
>>>> Ok, I looked at those functions. They return a BSTR, which is
>>>> ultimately an unsigned int, right? Or is it required for
HRESULT''s?
>>>>
>>> A BSTR is a pointer. It is defined in OLEAuto.h as follows:
>>> typedef OLECHAR FAR * BSTR;
>>>
>>> Ultimately we need a pointer type represented by unsigned long.
>>
>> Perhaps we should have ''l'' and ''L'',
''s'' and ''S''. The lowercase letters
>> would be signed and the uppercase would be unsigned. This would follow
>> the tradition of pack/unpack.
>>
> That''s OK.
Oops, that should have been ''i'' and ''I'', not
''s'' and ''S''.
>>>> I''m just trying to make sure I understand where and
why we need it so
>>>> I can document it clearly if/when we add a
''U'' type. It will also mean
>>>> having to update windows-pr I suppose.
>>>>
>>> I think we need signed long type instead of unsigned long.
>>> A lot of API functions return unsigned long such as DWORD, HANDLE,
BOOL.
>>>
>>> The function GetFileAttributes also returns DWORD value.
>>> And INVALID_FILE_ATTRIBUTES is not -1 but defined as
>>> #define INVALID_FILE_ATTRIBUTES ((DWORD)-1)
>>
>> It seems strange to cast -1 like that. Is it just to avoid warnings?
>>
> Not a strange to me. (DWORD)-1 is 0xFFFFFFFF.
>
>> In any case, how do we handle this in a generic way? I mean,
>> GetFileAttributes returns a DWORD, but we have to be able to return
>> the possibility of -1, right?
>>
> If a function returns DWORD type, the return value cannot be -1. -1 is
> human readable value. It is actually 0xFFFFFFFF.
Alright, then I should probably change INVALID_HANDLE_VALUE to
0xFFFFFFFF, and revert ''L'' to an unsigned long. I think there
are a
handful of other -1 values that should be changed then, too, in
windows-pr.

Regards,

Dan

Hi,

<snip>
>> If a function returns DWORD type, the return value cannot be -1. -1 is
>> human readable value. It is actually 0xFFFFFFFF.
>
> Alright, then I should probably change INVALID_HANDLE_VALUE to
> 0xFFFFFFFF, and revert ''L'' to an unsigned long. I think
there are a
> handful of other -1 values that should be changed then, too, in
> windows-pr.
FYI, here are the current values set to -1 in windows-pr that may need
to be changed:

C:\Documents and
Settings\djberge\workspace\windows-pr\lib\windows>findstr /s
/c:"-1$"
/r *.rb
com\variant.rb:         VARIANT_TRUE  = -1
com.rb:      DISPID_UNKNOWN     = -1
file.rb:      MAILSLOT_NO_MESSAGE            = -1
file.rb:      MAILSLOT_WAIT_FOREVER          = -1
file.rb:      INVALID_FILE_ATTRIBUTES  = -1
file.rb:      INVALID_HANDLE_VALUE     = -1
file.rb:      INVALID_SET_FILE_POINTER = -1
handle.rb:      INVALID_HANDLE_VALUE           = -1
mailslot.rb:      MAILSLOT_WAIT_FOREVER = -1
mailslot.rb:      MAILSLOT_NO_MESSAGE   = -1
network\management.rb:         MAX_PREFERRED_LENGTH = -1
thread.rb:      THREAD_PRIORITY_BELOW_NORMAL  = -1

Regards,

Dan

On Fri, Aug 21, 2009 at 7:35 PM, Daniel Berger<djberg96 at gmail.com>
wrote:
> Hi,
>
> <snip>
>
>>> If a function returns DWORD type, the return value cannot be -1. -1
is
>>> human readable value. It is actually 0xFFFFFFFF.
>>
>> Alright, then I should probably change INVALID_HANDLE_VALUE to
>> 0xFFFFFFFF, and revert ''L'' to an unsigned long. I
think there are a
>> handful of other -1 values that should be changed then, too, in
>> windows-pr.
>
> FYI, here are the current values set to -1 in windows-pr that may need
> to be changed:
>
> C:\Documents and
> Settings\djberge\workspace\windows-pr\lib\windows>findstr /s
/c:"-1$"
> /r *.rb
> com\variant.rb: ? ? ? ? VARIANT_TRUE ?= -1
> com.rb: ? ? ?DISPID_UNKNOWN ? ? = -1
> file.rb: ? ? ?MAILSLOT_NO_MESSAGE ? ? ? ? ? ?= -1
> file.rb: ? ? ?MAILSLOT_WAIT_FOREVER ? ? ? ? ?= -1
> file.rb: ? ? ?INVALID_FILE_ATTRIBUTES ?= -1
> file.rb: ? ? ?INVALID_HANDLE_VALUE ? ? = -1
> file.rb: ? ? ?INVALID_SET_FILE_POINTER = -1
> handle.rb: ? ? ?INVALID_HANDLE_VALUE ? ? ? ? ? = -1
> mailslot.rb: ? ? ?MAILSLOT_WAIT_FOREVER = -1
> mailslot.rb: ? ? ?MAILSLOT_NO_MESSAGE ? = -1
> network\management.rb: ? ? ? ? MAX_PREFERRED_LENGTH = -1
> thread.rb: ? ? ?THREAD_PRIORITY_BELOW_NORMAL ?= -1
Most of these were changed in windows-pr 1.0.8. A couple of them were
not modified, e.g. THREAD_PRIORITY_BELOW_NORMAL since it''s a valid
input value.

Regards,

Dan