[GRASS5] raster filename length problem

[Markus Neteler]

On Wed, Jul 13, 2005 at 05:11:25PM +1200, Hamish wrote:
> > > More generally, it would help if we had standardised NAME_MAX and
> > > MAPSET_MAX constants, rather than having arbitrary integer literals
> > > scattered all over the code.
> > 
> > I'll try whenever I come across NAME/MAPSET definitions to set them
> > to NAME_MAX,MAPSET_MAX. Before adding those to gis.h, how long?
> > Is 100 ok during the migration to NAME_MAX,MAPSET_MAX? I'm not
> > sure how to capture string overflows.
> 
> 
> From memory- Mac OS9 was 40 chars, OSX is unix so fs dependent?; K3B
> reports Joliet FS is 103 chars, something is 31 chars, some are 37
> (maybe that was where I was getting 40 from for OS9).
> 
> So should NAME_MAX,MAPSET_MAX be 128 to not be the limiting factor in
> all (reasonable) cases?  At least bigger than Joliet?
> 
> Does this affect a large MAX_FILES setting much or is it too small a
> component to matter?
> 

I have added
#define GNAME_MAX 50
#define GMAPSET_MAX 50

to include/gis.h and modified lib/gis/ and a couple of modules to
use the global definition. Note that NAME_MAX is already used somewhere
deep in the Linux system includes.

In a similar way I have touched
include/imagery.h
and lib/imagery/ to use INAME_LEN (which is still only 30 chars long).

As a test I have locally changed GNAME_MAX/GMAPSET_MAX to a length of
100 chars and voila', the earlier reported problem of
r.reclass.area/d.rast is solved!

TODO:
- please update from CVS and try longer GNAME_MAX/GMAPSET_MAX/INAME_LEN
- fix overseen hardcoded name/mapset definitions in CVS accordingly
- report success/problems to this list
- once stabilized, we can extend it in CVS.


Markus