[GRASS-dev] Usage of size_t

[Glynn Clements]

Markus Metz wrote:

> > I'm moving size_t topic from user to dev list.
> >
> > As I understand, size_t should be used also for number of rows and
> > number of columns of a map. But for example Rast_window_{rows,cols}
> > returns int. So will this be also changed/fixed to size_t?
> 
> Considering current hardware, we struggle to support maps with
> 2147483647 (the maximum value representable by a 32-bit integer;
> Glynn's previous answer) cells = rows * columns. Therefore I guess
> that for the time being int is fine as data type for rows and columns.
> Supporting 2147483647 rows x 2147483647 columns is still a far way to
> go. Type size_t should be used for rows * columns * sizeof(some data)
> when allocating memory, and type off_t should be used for rows *
> columns * sizeof(some data) for disk IO. I would just cast as
> suggested by Glynn.

FWIW:

size_t is specified by the C standard as the type of a "sizeof"
expression. It's used in the library as the argument to malloc(), and
wherever an array size is specified (e.g. memcpy, fread, etc).

On systems with a flat address space (i.e. anything which GRASS
targets), size_t will have the same size as a pointer.

off_t isn't specified by the C standard, but by POSIX, and refers to
the type used by lseek() to store a file offset. On 32-bit systems,
off_t may be either 32 or 64 bits. off_t is a signed type.

If you're going to read an entire map into memory, then using size_t
for the number of cells or bytes is sufficient for any map which will
actually fit into memory.

OTOH, if you're processing the file row-by-row, it may not actually be
possible to calculate the total number of cells or bytes.

For any file which can be opened, off_t is guaranteed to be large
enough to represent the size of the file on disk; without LFS, the OS
will refuse to open a file larger than 2GiB.

However, GRASS raster maps are normally compressed, so the number of
bytes or cells in the decompressed data may exceed 2^31 even if the
file is smaller than 2 GiB.

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