[GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

[GRASS GIS]

#2031: G_legal_filename() cleanup patch for GRASS 6
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  grass-dev@…              
      Type:  defect   |      Status:  closed                   
  Priority:  normal   |   Milestone:  6.4.4                    
 Component:  LibGIS   |     Version:  svn-releasebranch64      
Resolution:  fixed    |    Keywords:                           
  Platform:  All      |         Cpu:  All                      
----------------------+-----------------------------------------------------

Comment(by glynn):

 Replying to [comment:12 mlennert]:

 > Legitimate question: it seems to me that r32820 mixes cases where the
 output are (non-GRASS element) files (e.g. r.kappa) with cases where the
 output are GRASS element files (e.g. r.buffer, r.median, r.neighbors). Why
 was the change necessary/advisable for the latter ?

 G!__open_raster_new() accepts a fully-qualified name for an output map, so
 long as the mapset matches the current mapset. G!__open_raster_new()
 performs this check, removes any @mapset part, then performs the
 G_legal_filename() check on the unqualified name.

 So a G_legal_filename() call in the module is typically redundant (the
 open_new function will reject invalid names soon enough), and will reject
 qualified names which may otherwise work fine. I say "may" because I don't
 know whether the functions for writing support files (history, colour
 tables, etc) also cope with qualified names.

 If the G_legal_filename() calls are required to protect functions other
 than G_open_*_new(), they should remain. Otherwise, they should be
 removed.

 In 7.x, the library functions are quite consistent about accepting
 qualified names. Modules should normally be able to pass names from option
 values straight through to library functions without any checks or
 parsing. The only cases which are problematic are where an option
 specifies a base name to which a suffix is appended (i.e. you need to
 generate map.suffix at mapset, while simply appending the suffix will produce
 map at mapset.suffix), modules which explicitly deal with mapsets or
 locations (e.g. r.proj), or database-management utilities (e.g. g.mlist).

 Having said that, it would have been better if r32820 had been split into
 separate patches, one to remove bogus checks (e.g. names of non-GRASS data
 files) and another to remove redundant checks.

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