[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 hamish):

 Would it not have been better to replace G_legal_filename() with some
 G_legal_mapname() than to just remove all the safety checks?

 cell/mapname is by definition a filesystem name, so G_legal_filename()
 seems perfectly legitimate safety check.

 see https://trac.osgeo.org/grass/ticket/2025#comment:9

 and comment 8, just above it: "OK no problem, proposed backport of r32820
 deleted."


 This seems more like refactoring than specific bug fixing to me, so not
 really appropriate for 6.x anyway, and certainly not something to do just
 before releasing 6.4.4. Have the appropriate checks been added in libgis
 for all functions which will fail?


 Also there is refactoring of v.random.surface and r.surf.fractal, was that
 intended to be in this commit?


 I suggest to revert -- and not commit large patches to relbr64 directly!
 Especially when we are trying to get a release out the door!!


 thanks,
 Hamish

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