[GRASS5] Re: [GRASS-CVS] glynn: grass51/general/g.parser main.c,2.0,2.1

Glynn Clements glynn at gclements.plus.com
Mon Dec 6 10:11:44 EST 2004


Hamish wrote:

> > > does the change below affect existing GRASS scripts?
> > 
> > > > -	sprintf(buff, "GIS_OPT_%s=%s", option->key, option->answer);
> > > > +	sprintf(buff, "GIS_OPT_%s=%s", option->key, option->answer ? option->answer : "");
> > 
> > The only way in which it could affect existing scripts is if they are
> > doing e.g.:
> > 
> > 	if [ $GIS_OPT_something = '(null)' ] ; then
> > 		...
> > 
> > which is probably a bug. I'm not sure that sprintf(buff, "%s", NULL)
> > is guaranteed to generate "(null)".
> > 
> > However, there is at least one script (i.image.mosaic) which expects a
> > missing argument to result in $GIS_OPT_* being the empty string.
> > 
> > N.B.: this is a fix for bug #2740.
> 
> grass57/scripts$ grep -r '(null)' * | cut -f1 -d/ | uniq
> d.monsize
> d.out.png
> d.rast.leg
> d.slide.show
> g.manual
> g.mlist
> g.mremove
> i.spectral
> r.out.gdal
> r.reclass.area
> r.shaded.relief
> v.in.garmin
> 
> Is the above change permanent and should all these scripts change to 
> 
> - if [ $GIS_OPT_something = '(null)' ] ; then
> + if [ -z $GIS_OPT_something ] ; then
>    ...

Yes.

> either way is ok, but we need to pick one way and stick with it.

Using (null) assumes that printf("%s") will represent null pointers
that way (rather than just e.g. segfaulting).

The fix has the disadvantage that you can't distinguish between an
omitted option and one which was explicitly set to the empty string. I
don't know if that really matters.

If it's essential to be able to distinguish these two cases, there
will need to be an extra variable for each option, e.g. 
$GIS_OPT_USED_something.

[With the original, you can't distinguish between an omitted option
and one which was explicitly set to "(null)", but that's even less
likely to matter.]

> 'db.connect -p' also shows (null) from a new mapset.

Ideally that should be fixed, e.g.

-	printf("... %s ...", ptr)
+	printf("... %s ...", ptr ? ptr : "(none)");

According to ANSI C, the effect of passing a null pointer for %s is
undefined, so we shouldn't do it.

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




More information about the grass-dev mailing list