[GRASS-dev] [GRASS GIS] #1662: Caching bug in 3D raster library with large data

[GRASS GIS]

#1662: Caching bug in 3D raster library with large data
-------------------------------------+--------------------------------------
 Reporter:  huhabla                  |       Owner:  grass-dev@…              
     Type:  defect                   |      Status:  new                      
 Priority:  critical                 |   Milestone:  7.0.0                    
Component:  Raster3D                 |     Version:  svn-trunk                
 Keywords:  3D raster, tiles, cache  |    Platform:  Linux                    
      Cpu:  x86-32                   |  
-------------------------------------+--------------------------------------

Comment(by glynn):

 Replying to [comment:8 hamish]:

 > I see many times "long"* is used as a variable type in lib/raster3D/,
 e.g.:
 > (* and some "unsigned long" too)

 Historically, most of my "bulk" fixes for things like LFS skipped over the
 raster3D library (because the number of cases in raster3D often exceeded
 those in the rest of the GRASS code base combined).

 > so to make it LFS compatible on 32bit those having to do with file
 offsets and cell counts should be changed to e.g. off_t or use a G_*()
 wrapper instead? (none for lseek(), but we do have G_ftell() and
 G_fseek())

 File offsets should use off_t.

 Cell counts ... are a problem. "long long" and "int64_t" aren't in C89,
 "long" is only 32 bits on 64-bit Windows, size_t is unsigned.

 Windows itself doesn't have off_t (or fseeko/ftello). The POSIX functions
 in MSVCRT use either int (e.g. read, write) or long (e.g. lseek). Some of
 them have 64-bit variants using !__int64 (e.g. _lseeki64, although the
 name has changed between MSVCRT versions).

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1662#comment:10>
GRASS GIS <http://grass.osgeo.org>