lib/diglib: fix integer overflow

[metzm]

This PR fixes an integer overflow when writing out spatial index files (sidx) larger than 2GB. With the integer overflow, the resultant file size is underestimated, a wrong size for writing out file offsets is used and the spatial index file becomes unreadable. Other potentially large vector files (coordinates, topology, category index) are not affected.

[nilason]

Looks good to me!

FYI, this is listed among another 100+ similar overflow issues in the CodeQL CI check.
Out of curiosity: I assume you hit upon this as a bug (segfault or similar) running some code, was it difficult to the track this down?

[metzm]

FYI, this is listed among another 100+ similar overflow issues in the CodeQL CI check.

An integer overflow can happen whenever two integer values are added, subtracted, or multiplied, right? It is practically impossible to cast the operation to the next larger integer type. One exception in GRASS is, we should use grass_int64 for the number of raster cells = rows * columns.

Out of curiosity: I assume you hit upon this as a bug (segfault or similar) running some code, was it difficult to the track this down?

The error message came from G_fseek(), reason being an invalid offset argument. Once I got a sample vector to reproduce this error, it was relatively easy to trace down the bug.

[nilason]

FYI, this is listed among another 100+ similar overflow issues in the CodeQL CI check.

An integer overflow can happen whenever two integer values are added, subtracted, or multiplied, right? It is practically impossible to cast the operation to the next larger integer type. In GRASS, we should do this for the number of raster cells = rows * columns.

The issues reported by CodeQL are arithmetics (multiplication) on smaller types which result is stored to a larger type. This reflects the programmers expectations, e.g.:

size_t size;
int a, b, c;

size = a * b; // in this case multiplication precedes the (implicit) cast and its result may be overflowed

size = (size_t)a * b; // the cast precedes the multiplication, no problems

c = a * b; // the programmer don't expect larger result, no problems

This is why the CodeQL issues only are numbered in the hundreds (and not thousands).

Out of curiosity: I assume you hit upon this as a bug (segfault or similar) running some code, was it difficult to the track this down?

The error message came from G_fseek(), reason being an invalid offset argument. Once I got a sample vector to reproduce this error, it was relatively easy to trace down the bug.

Good to hear. Once I, or someone else, manage to fix those relatively simply fixed CodeQL issues, another potential similar bug to this will be avoided.