2017-07-29 12:38:12 UTC
I have a portability layer for I/O. It is meant to be portable across dialects, compilers and operating systems. A configuration script lets users choose what underlying library to use (PIM, ISO, POSIX or vendor library). The choices depend on the dialect, the compiler and operating system.
As I am implementing the portability layer for use with the ISO library underneath, in particular a procedure that gets the size of a file, the ISO library type FilePos is giving me some headache.
I need to be able to do arithmetic operations on values of type FilePos in order to determine whether a value returned by RndFile.EndPos() would overflow type FileSize defined by my portability layer which is either CARDINAL or LONGINT depending on environment and configuration. If it does, I set a status SizeOverflow, which may happen when a compiler only supports 32 bit but produces code that runs on a 64 bit platform trying to get the file size of files larger 2 or 4 GB. A small price to pay for portability.
Anyway, I discovered that the p1 compiler does not permit arithmetic on values of type FilePos, nor does it permit conversion to another type. Astonishingly, this does not even appear to violate the ISO standard which defines type FilePos as an array of LOC of an implementation defined size. It does not seem to mandate that one can do arithmetic on values of the type, nor conversion.
Thus, when using the p1 compiler, I cannot convert the file size returned by RndFile.EndPos() nor could I check whether or not it would overflow my FileSize type. I had no choice but to open the file and read it byte by byte to the end while incrementing a counter in order to obtain a file size that is actually of any use. Very inefficient on larger files, but there seems to be no other way with p1's ISO library.
Now, I am wondering how many other ISO compilers (if any) suffer from the same silliness.
The operations I use can be seen in this function which checks whether an overflow would occur:
if the test determines that no overflow would occur the value is simply converted using VAL().
I would appreciate if group readers could check with whatever ISO compiler they have access to whether or not their compilers permit these arithmetic operations on values of type FilePos and conversion to CARDINAL and LONGINT.
thanks a lot in advance.