John M McIntosh wrote:
Mmm no, the history of the squeakFileOffsetType was originally for the use of file system 64bit points back when 64bit support Windows was a footnote in some Microsoft engineers diary. It was first introduced on the mac version of the VM with other variations following years? later.
Technically it is a platform specific entity since not all file systems support 64bit values, so it's improper to consider for other usages outside the file system support plugins.
That may be true but these platforms can still return 64 bit values (and fail if the request is larger than 32 bit). I think Eliot's suggestion is a good one: Make all file operations take 64 bit, leave it to the vm implementors to deal with the consequences, and alias squeakFileOffsetType to usqLong (or get rid of it).
Cheers, - Andreas
On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
Igor Stasenko wrote: Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead. I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers, - Andreas
--
John M. McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================