[GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing

[Markus Neteler]

On Thu, May 23, 2002 at 05:36:04AM -0600, Roger Miller wrote:
> On Thursday 23 May 2002 02:26, Markus Neteler wrote:
> 
> > Following fix cures the problem for env.c:
> > cvs diff -u env.c
> > RCS file: /grassrepository/grass/src/libes/gis/env.c,v
> > retrieving revision 1.5
> > diff -u -r1.5 env.c
> > --- env.c       12 May 2002 12:04:45 -0000      1.5
> > +++ env.c       23 May 2002 08:25:33 -0000
> > @@ -177,13 +177,12 @@
> >      int n;
> >
> >      for (n = 0; n < count; n++)
> > -       if (env[n].name && (strcmp(env[n].name, name)==0))
> > +       if (env[n].name && (strlen(name)!=0) && (strcmp(env[n].name,
> > name)==0)) {
> >             free (env[n].name);
> >             env[n].name = 0;
> >             return 1;
> >         }
> > -
> >      return 0;
> >  }
> >
> > Objections to submit this fix?
> 
> Markus, if an empty string caused the problem, then maybe a better fix would 
> be to change set_env so that an empty string never stored.  An empty string 
> could be treated like a NULL.  
> 
> At line 125 in env.c the statement
> 
> if(!value)
> 
> could be changed to 
> 
> if(!value || !strlen(value))
> 
> That way an empty string is treated the same way as sending a NULL string and 
> causes GRASS to unset the environment variable.

This change is working - I have reverted mine and submitted yours to
CVS.

> > But...
> > Then the next bug occurs due to the new NAD datum support:
> > In r.proj/main.c line 279 is the function G_database_datum_name() used:
> >    strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
> > For my existing locations it returns NULL which causes a crash
> > of strncpy(). The function G_database_datum_name() is in
> > src/libes/gis/proj3.c
> >
> > How to solve that one (hi Roger)? Therefore [vs].proj are also affected.
> 
> Uhh.  I guess I did know about that problem.  A check is easily added.  My 
> preference would be also to change G_database_datum_name() so that it does 
> not return NULL (maybe returning a pointer to "unknown" instead) and/or 
> ensuring that the datum is never blank.

Latter is not possible (backward compatibility, since map datum recording 
was implemented not too long ago). Please submit the proposed fix (check).

Thanks,

 Markus