[GRASS5] g.region G_usage() commented out?

[Glynn Clements]

Eric G. Miller wrote:

> > What about changing die() so that it also prints the ->description
> > string?  Like the diff below?  It's not perfect, but it's an
> > improvement.
> > 
> > diff -u -r1.8 main.c
> > --- src/general/g.region/cmd/main.c     22 Jan 2002 04:51:04 -0000      1.8
> > +++ src/general/g.region/cmd/main.c     15 May 2002 04:34:35 -0000
> > @@ -704,7 +704,7 @@
> >  
> >  static void die(struct Option *parm)
> >  {
> > -       fprintf(stderr,"<%s=%s> ** illegal value **\n\n", parm->key, parm->answer);
> > +       fprintf(stderr,"<%s=%s> not recognized, expecting:\n%s\n", parm->key, parm->answer, parm->description);
> >         /*
> >      G_usage();
> >      */
> 
> I'm not sure that adds anything to the error report.  

Well, the description field will indicate that the format has to be
dd:mm:ss for lat/lon locations.

However, the mechanism which is used involves calling library
functions before G_parser() has returned, which would stop working if
we were implement "standard" options such as "location=".

> On a general note, would it be desirable to have G_{lat|lon|llres}_scan
> fall back to reading doubles and then range check the value?

I would say so.

> Nitpick: I dislike "illegal value". IMHO, "invalid input" is more
> "correct" since the law has nothing to do with the matter.  Also, no
> good reason not to use G_fatal_error() here.  Technically, exit(1) is
> not well defined either (exit(EXIT_FAILURE) is).

At least exit(1) is an improvement over exit(-1); the latter is all
too common. Also, while exit(1) may not be defined by ANSI C, the
various Unix specifications all dictate that zero indicates success
and non-zero indicates failure.

-- 
Glynn Clements <glynn.clements at virgin.net>