On 2025-11-25 23:27, Bart via fpc-devel wrote:

Hi Bart,

MS defines GetDiskFreeSpaceExW as follows:
(https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskfreespaceexw)

BOOL GetDiskFreeSpaceExW(
  [in, optional]  LPCWSTR         lpDirectoryName,
  [out, optional] PULARGE_INTEGER lpFreeBytesAvailableToCaller,
  [out, optional] PULARGE_INTEGER lpTotalNumberOfBytes,
  [out, optional] PULARGE_INTEGER lpTotalNumberOfFreeBytes
);

And ULARGE_INTEGER is a union representing a 64-bit unsigned integer value.

However in rtl/win/wininc/redef.inc we define 2 overloads for this function:

function GetDiskFreeSpaceExW(lpDirectoryName: LPWSTR; var
lpFreeBytesAvailableToCaller, lpTotalNumberOfBytes: TLargeInteger;
lpTotalNumberOfFreeBytes: PLargeInteger): BOOL;external 'kernel32'
name 'GetDiskFreeSpaceExW';
function GetDiskFreeSpaceExW(lpDirectoryName: LPWSTR;
lpFreeBytesAvailableToCaller, lpTotalNumberOfBytes: pLargeInteger;
lpTotalNumberOfFreeBytes: PLargeInteger): BOOL;external 'kernel32'
name 'GetDiskFreeSpaceExW';

I have 2 questions about this:
1. why do we use signed parameters instead of unsigned
(TULargeInteger/PULargeInteger)?
 (well, High(Int64) > 9223372 Tera, so it'll take some time before we
have disks where this will overflow)
2. since all out params are of the same type, why does the overload
with var parameters onlu use "var" for the first 2 params and not for
the last one?
 -> now I have to call this like GetDiskFreeSpaceExW(PWideChar(Drive),
Avail, Size, @FreeSize);

I know that having the third param being a pointer, you can set it to
nil if you're not interested in FreeSize, but the same argument can be
made for Size param.
Just use the overload with only pointer params for that IMO.

I'd guess that Delphi compatibility is the answer to both questions (https://docwiki.embarcadero.com/Libraries/Sydney/en/System.SysUtils.GetDiskFreeSpaceEx). Possibly due to Delphi not having 64-bit unsigned integer at some stage? Obviously, it would make sense to have an unsigned overload as well if nothing else.

Tomas
_______________________________________________
fpc-devel maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to