[Lazarus] INVALID_* consts

[waldo kitty]

On 6/26/2013 16:21, Hans-Peter Diettrich wrote:
> Simple solution:
>
> The INVALID_FILE_SIZE constant is used only inside Win32 RTL code, with API
> records or API functions returning exactly that type and value. This constant is
> not exported from the unit. Win32 specific user code, missing this constant
> value, has to be updated.

has to be updated how? i don't know that part... but i guess part of the problem 
is also the conversion from a DPR to a LPR replaces everything with LCL 
specifics which i'm still trying to learn as well :? :/

> The user only gets platform-independent int64 filesizes, and here -1 or every
> negative value can indicate an error.

i think i understand that... the problem is the conversion of DPR to LPR and 
what needs to be done after that to compile the project to even start any 
testing... perhaps this is due to not checking "support delphi"?? i dunno :(

> waldo kitty schrieb:
>> On 6/3/2013 18:54, Hans-Peter Diettrich wrote:
>>> waldo kitty schrieb:
>>>> what can we do about INVALID_FILE_SIZE?
>>>>
>>>> const
>>>> INVALID_FILE_SIZE = DWORD($FFFFFFFF);
>>>>
>>>> is the above correct? it would seem to be from what i can make out from MSDN
>>>> and the various C code files i've found it defined in...
>>>
>>> Using unsigned constants with int64 filesizes would classify files of exactly
>>> that size as invalid, while smaller or bigger files would be valid. This
>>> certainly is *not* what the coder had in mind, so that I'd suggest to inspect
>>> and fix all occurences of this (and similar) unsigned constants in user code.
>>
>> i'm (finally) back to trying to poke this conversion thing with a sharp
>> stick... i understand what you are saying in the above but i don't know how to
>> "fix all occurrences of this (and similar) unsigned constants in user
>> code."... i'm sure it is probably something easy that i'm not seeing...
>> something like adding a sign ;)
>>
>> eg: INVALID_FILE_SIZE = DWORD(-1);
>>
>> but how can i know if that will be what OS API functions send back? the above
>> const is documented as shown above in the DWORD form so i already know that
>> that particular instance from that particular API function will fail... since
>> DWORD($FFFFFFFF) <> -1...
>>
>>>> i kind of have to laugh because on place i read spoke of examples checking the
>>>> result directly instead of using INVALID_FILE_SIZE and that this was not good
>>>> coding practice because m$ might change the value of INVALID_FILE_SIZE at any
>>>> time which would then break all of that code... i makes sense to me O:)
>>>
>>> IMO such unsigned constants should be used only in specific cases, e.g. with OS
>>> defined records containing part of an longer (int64) type. The FCL can use that
>>> constant in Win32 platform code, the LCL or user code never should use it at
>>> all.
>>
>> i understand this... how can i get this const (as defined) into the FCL if it
>> does not already exist? how can i tell my converted delphi project to use the
>> FCL in addition to the LCL? right now when i look at the project inspector,
>> the LCL is the only "required" package shown...
>>
>>> I also doubt that the MS documentation is up to date whenever above constant is
>>> used with anything except struct fields of type DWORD. Even in 32 bit code
>>> *both* low/high parts of a 64 bit filesize must be checked for
>>> INVALID_FILE_SIZE, in order to determine a valid result.
>>
>> the documentation for the above const (which i linked to previously) talks
>> about using a different OS API function for those instances where necessary...



-- 
NOTE: No off-list assistance is given without prior approval.
       Please keep mailing list traffic on the list unless
       private contact is specifically requested and granted.