[GRASS-dev] vector large file support

Glynn Clements glynn at gclements.plus.com
Tue Feb 3 23:27:17 EST 2009


Markus Metz wrote:

> If the coor file size stored in the topo file is indeed needed to 
> properly process the coor file, the respective variables must be 
> something else than long in order to support coor files larger than 2 
> GB, maybe long long? Same for all intermediate variables in the vector 
> library storing coor file size.
> Looking at limits.h, long can be like int or like long long (only true 
> 64 bit systems). I use Linux 64bit with 32bit compatibility, here long 
> is like int. Someone more familiar with type limits and type 
> declarations on different systems please help!

As you note, long will normally be the largest size which the CPU can
handle natively, while long long (only available in C99 or as a gcc
extension) can be expected to be 64 bits where it exists. FWIW, "int"
can theoretically be 64 bits, but this is rare.

The correct type to use for the size of a file is off_t, which can be
made to be a 64-bit type by adding -D_FILE_OFFSET_BITS=64 to the
compilation switches. This should only be done if $(USE_LARGEFILES) is
non-empty (corresponding to --enable-largefile).

However, that alone isn't sufficient, as you have to explicitly force
offset calculations to be performed using off_t rather than int/long,
e.g.:

	long idx, step;
	...
	off_t offset = (off_t) idx * step;
or:
	off_t offset = idx * (off_t) step;

Note that:

	off_t offset = idx * step;
and:
	off_t offset = (off_t) (idx * step);

won't work, as the result isn't up-cast until after it has been
truncated.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list