[GRASS5] features needed for 6.2

[Glynn Clements]

Markus Neteler wrote:

> > I feel really good about where 6.1-cvs is right now; 64bit & large file
> > bugs are still trickling in (as expected), but otherwise things are
> > pretty strong.
> 
> Well, 64bit is doing pretty well AFAIK (only 64bit machines in the office
> now). Large file is causing problems, Glynn had commented on this but
> then the issue disappeared. Maybe his grass-header-fix script could also
> do the config.h trick which he suggested?

I wouldn't recommend trying to automate it.

Code shouldn't be attempting to use LFS unless it has been written to
allow for it, i.e. using size_t rather than int/long; not just in
variable declarations, but in expressions as well.

This is why glibc doesn't enable LFS by default; if your code doesn't
handle offsets >2Gb correctly, the safest solution is to simply refuse
to deal with such large files (i.e. don't use open64() or O_LARGEFILE).

If someone modifies a source file to cope with LFS, adding the
"#include <grass/config.h>" is trivial. If the source hasn't been
modified to cope with LFS, it /will/ fail on large files. The failure
mode provided by the kernel (an explicit error) is preferable to the
failure mode arising from a wrapped offset (silently corrupting data
or producing garbage results).

Actually, as source files might include config.h for reasons other
than LFS, the safest solution would be not to define system macros
such as _FILE_OFFSET_BITS directly in config.h, but to define a
private macro (e.g. GRASS_LARGEFILE) and require individual source
files to explicitly enable LFS with e.g.

	#include <grass/config.h>
	#ifdef GRASS_LARGEFILE
	# define _FILE_OFFSET_BITS 64
	#endif
	
	#include <stdio.h>
	#include <unistd.h>
	/* etc */

This would ensure that code which isn't LFS-capable doesn't enable LFS
accidentally.

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