Consider limiting size of read/write/seek to INT32_MAX

[jphickey]

Is your feature request related to a problem? Please describe.
The OSAL API returns results as int32, and this includes the size of data read/written from operations like OS_read and OS_write. However it is possible to read/write a larger buffer than what can be expressed as int32. If this overflow happens then the result is likely to become negative and be interpreted as an error.

Describe the solution you'd like
OS_read and OS_write should probably cap the amount they will transfer in a single call to be INT32_MAX. This should in turn limit the size of the result that would need to be returned to the caller.

OS_lseek() returns the file offset, so this probably doesn't work with files bigger than 2GB.

Describe alternatives you've considered
Use a larger data type e.g. int64 as return, but this is potentially slow on 32 bit CPUs where 64 bit values may need to be emulated by the C library.

Additional context
If size_t (buffer size parameter) is 64 bits and the return value is 31 bits (usable) then there is a large set of potential values which are not representable.

However - this problem has existed even when the input size was uint32 rather than size_t ... because anything bigger than INT32_MAX is a problem - so this isn't new, its just potentially more of a concern with large files./file systems and 64 bit platforms.

Read/Write actions should always be allowed (per API) to transfer fewer bytes than the request was for - app should retry with the remainder. So capping at INT32_MAX should not be a problem - no app should expect an extremely large transfer like that to happen in one go.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[skliper]

I'm in favor of it. Quick fix? If so I'd like to resolve for Caelum.