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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev