[GRASS-user] problems with r.cost

[Glynn Clements]

William Kyngesburye wrote:

> > The large file support option doesn't help with all grass routines
> > unfortunately.
> >
> > The following has to be in the Make file for the specific module
> >
> > ifneq ($(USE_LARGEFILES),)
> >         EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64
> > Endif
> >
> > It is not in the r.cost Make file, which means I think (remember  
> > I'm not a C
> > programmer) that compiling with large file support won't help.
> 
> The need for FILE_OFFSET_BITS and its many variations should be  
> discovered by configure, and whatever is needed by a platform is set  
> in config.h, so this setting here is redundant and possibly  
> meaningless on some platforms.

The settings in config.h are conditionalised upon USE_LARGEFILES,
which is never defined automatically.

If you want LFS, you have to add the relevant flags in the
corresponding Makefile. But first you need to ensure that the code is
actually safe for LFS (i.e. it doesn't use ANSI stdio functions or
store offsets in variables smaller than an off_t) if you don't want
corrupted files.

> (OSX doesn't need any of the macros set, and supports large files by  
> default.)

Unfortunately, much of GRASS doesn't support LFS (especially, but not
exclusively, on platforms where sizeof(long) < sizeof(off_t)), so
enabling it globally is dangerous. That's why you normally have to
specifically enable it with _FILE_OFFSET_BITS etc.

On platforms with a 64-bit "long", you only have to worry about "bad"
code (storing or computing offsets using "int"); even so, GRASS isn't
entirely free from bad code.

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