[Lazarus] INVALID_* consts

[waldo kitty]

On 6/3/2013 18:54, Hans-Peter Diettrich wrote:
> waldo kitty schrieb:
>> 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.

have you read the links i provided? exactly this situation is discussed in 
several of them ;)

>> 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.

without it, it makes porting harder... especially when one is not familiar with 
the integral parts of any OS... while i've been coding for 30+ years, i've never 
done any GUI coding so the easier it is to make conversions happen, the better 
for all... IMHO, of course...

> 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.

as i point out above, the documentation speaks specifically about this and it 
does give an alternative...

in specific to the code i'm looking to port, yes, the coders did intend this 
because that is how things were done at that time... 4Gig files were/are unheard 
of in that environment and still are today... there's no way we're going to be 
transferring 4Gig files... we won't even transfer those of 200+Meg in our hobby 
network... things may change in the future but until then, there are other 
technologies available for transferring such large files... especially if one is 
on dial-up making direct connections to the remote sites... i won't even mention 
the use of 9600 "baud" radio for the same ;)

-- 
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.