[GRASS5] Re: [GRASSLIST:778] Re: Problem GRASS-6.0.2

[Glynn Clements]

Hamish wrote:

> > If the --enable-largefile configure option is used, the header
> > <grass/config.h> will define some macros which cause off_t to be
> > defined as a 64-bit type and the I/O functions declared in <unistd.h>
> > to be the 64-bit versions (open64 etc).
> > 
> > If a module only does sequential file access (open, read/write,
> > close), including <grass/config.h> before any other headers will be
> > sufficient (note that <grass/gis.h> includes <grass/config.h>).
> 
> 
> does this mean as standard practice in most modules we should be
> using this order:
> 
> #include <grass/gis.h>
> #include <stdio.h>
> #include <string.h>
> ..
> #include <grass/raster.h>
> #include "local_proto.h"
> 
> or this:
> 
> #include <grass/config.h>
> #include <stdio.h>
> #include <string.h>
> ..
> #include <grass/gis.h>
> #include <grass/raster.h>
> #include "local_proto.h"
> 
> or this:
> 
> #include <stdio.h>
> #include <string.h>
> #include <grass/config.h>
> #include <unistd.h>
> ..
> #include <grass/gis.h>
> #include <grass/raster.h>
> #include "local_proto.h"

No (none of the above).

Modules which specifically want LFS (i.e. those that can cope with it)
should use either the second or third options, depending upon whether
you want to access large files using ANSI stdio (you still won't be
able to seek on such files; it will just prevent fopen() from failing
on files >2Gb).

However, unless someone is planning on making the whole of GRASS
LFS-aware soon, the LFS support should be fixed so that it isn't
enabled just by including <grass/config.h>. As it stands,
--enable-largefile is too dangerous.

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