[Win32utils-devel] [Fwd: Re: FW: win32-api, unsigned long vs long in api_call]
djberg96 at gmail.com
Fri Aug 21 21:29:41 EDT 2009
On Fri, Aug 21, 2009 at 7:02 PM, Daniel Berger<djberg96 at gmail.com> wrote:
> Moving this conversation over to win32utils-devel...
> 2009/8/22 Daniel Berger <djberg96 at gmail.com>:
>>>> 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
More information about the win32utils-devel