Migrating C software to 64-bit file pointers (changes)

Showing changes from revision #1 to #2: Added | Removed | Changed

The new features described herein were introduced in versions of the C library and the stubs, built from the “RISC_OSLib” component, version 5.64. They depend upon changes to the header file stdio.h, but note that the C compiler uses a built-in copy of this and other standard headers (for speed) by default. The built-in headers will be updated for the next release, cc version 5.70, but it is possible to use the new API on an older compiler by forcing the use of the disc-based version of the header, which is achieved by adding -jC: to the cc command line.

Most of the ISO C library function definitions are file size agnostic, using abtract data types. The exceptions to this are the functions fseek() and ftell(), which are specified in the C standard to use “long int” types, which are defined to be signed 32-bit numbers on RISC OS, as on most other systems. These cannot be changed without breaking ISO conformance.

So the first step to migrating to larger files is to replace all calls to fseek() and ftell() to fseeko() and ftello(), which are similar, but take a new, abstract type, off_t, as the relative file pointer type. To enable these new functions in stdio.h, you must define _LARGEFILE_SOURCE, either with a -D switch on the command line, or by using #define in your source file before you #include <stdio.h>.

You will then need to link your object files with a new version of the stubs, but the resultant binary will still run on systems which have an older version of the shard shared C library module installed. Note that this is the only extension which is available for code compiled inPCC mode.

As described in the rationale for the LFS extensions, any file descriptor opened using the traditional fopen(), freopen() or tmpfile() functions will be limited to 2GB-1 in size. Any attempt to read, write or seek outside this range will result in failure, and errno will be set to EOVERFLOW or EFBIG (which are new error numbers for the shared C library).

To enable 64-bit file pointers in your software, you have two options:

1) Selectable off_t. This will leave your source code largely untouched, except for the substitution of fseeko() and ftello() as described above, but means you have the responsibility to ensure that all object files and static libraries have been compiled using the same settings, or the results will be unpredictable. Simply define _FILE_OFFSET_BITS=64, either on the command line or before you #include <stdio.h>. A 32-bit file pointer version of the application can still be built by simply removing this definition, or by setting it to 32.

2) Explicit off_t. This involves changing your source code to use the types fpos64_t and off64_t, and the functions fgetpos64(), fopen64(), freopen64(), fseeko64(), fsetpos64(), ftello64() and tmpfile64(). To enable these types and functions, you need to define _LARGEFILE64_SOURCE in a similar way to the other options described above.

Whichever option you choose, you will not only need to use the new stubs, but also RMEnsure SharedCLibrary 5.64 in order to run the resulting binary.