Forum > Windows
SetFilePointerEx function missing
Fibonacci:
--- Quote from: Thaddy on November 07, 2024, 02:22:47 pm ---I think some other people need more coffee. Why a signed type? Deliberately half your reach?
--- End quote ---
Because:
--- Quote ---LARGE_INTEGER = Represents a 64-bit signed integer value.
Your C compiler may support 64-bit integers natively. For example, Microsoft Visual C++ supports the __int64 sized integer type. For more information, see the documentation included with your C compiler.
--- End quote ---
--- Quote from: Thaddy on November 07, 2024, 02:22:47 pm ---Deliberately half your reach?
--- End quote ---
Thats 8388608 TB of data anyway
Thaddy:
See the response that Microsoft gave me. posts crossed.
The signed type is just for historical reasons and backwards (curious which backwards?) compatibility.
Second answer:
"Haha, I get where you're coming from! The decision to use LARGE_INTEGER for file sizes in Windows APIs does seem a bit like a relic from the past, much like the infamous "640K ought to be enough for anybody" quote attributed to Bill Gates (though he denies ever saying it).
The use of LARGE_INTEGER is indeed a historical artifact, designed to maintain backward compatibility with older applications. While it does limit the range to half of what an unsigned 64-bit integer could offer, the practical limit is still vast—about 9.22 exabytes, which is more than sufficient for most current applications."
Now only who will pay my coffee..... >:D
(and yes, I dropped the 640k )
Fibonacci:
Actually you are half right :o
--- Quote ---The starting point is zero or the beginning of the file. If this flag is specified, then the liDistanceToMove parameter is interpreted as an unsigned value.
--- End quote ---
This is the case if dwMoveMethod is FILE_BEGIN, but not for the other 2 flags.
EDIT: Ok, thats for the liDistanceToMove, you are talking about the pointer, that is lpNewFilePointer, I guess that could be PUInt64.
Thaddy:
Did anybody miss the "more than sufficient"" part?
To paraphrase "A comedy of errors."
And yes, this is an official MS point of view.
440bx:
It really doesn't matter that the file pointer cannot be negative. What matters is that it was originally defined by the O/S creators using LARGE_INTEGER and that will suffice for quite some time. Therefore there is no good reason at this time to change it and risk breaking compatibility problems with existing apps.
I think it's much more useful to have the definition using int64 and pint64 because it's much more convenient than dealing with the LARGE_INTEGER structure. That makes a difference and does not affect compatibility.
When 63 bits become insufficient (don't hold your breath for that one), MS will have SetFilePointerEx2 that will use a 64 bit unsigned parameter thus allowing Thaddy to have one less thing to worry about ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page