[GRASS5] segment lib speed patch

[Glynn Clements]

Hamish wrote:

> > +	    return -1;
> 
> 
> For a long time I have wondered what is best to use for return codes;
> most modules return 0 for success as per UNIX norms, library fns return
> all sorts of things, e.g. often 1 for true, etc.. glibc has the same
> issues with e.g. strcmp(), and I understand is_foo() returning
> TRUE/FALSE.

Predicates (pure functions which return truth values), e.g. the
isXXX() functions in ctype.h, normally return C truth values, i.e. 
zero for false, non-zero for true.

Functions for which non-negative integers (include zero) are valid
results normally use -1 for errors.

Procedures which return a status typically use zero for success, and
-1 for errors, as that is how most system calls behave.

strcmp() returns -1, 0 or 1 for <, == or > respectively. Comparison
functions used by qsort() use the same convention.

> esp. for all the  if(G_parser()) exit(-1);  statements in the modules.
> Should that really be -1 or just 1 or does it matter?

It should be 1. Returning a negative value from main() is bogus. In
practice, it will typically be equivalent to returning 255 (the exit
code is usually 8 bits wide, although I'm not sure if this is mandated
by any formal standard).

> It would be nice if we had something standard we could put in the
> SUBMITTING file. (e.g. action fn()s return 0 on success, test fn()s
> return 1, or something like that?)
> 
> Specifically: should we avoid return -1; ??

We should avoid returning -1 from main() and exit(-1).

It's a sensible return value for functions, particularly where all
non-negative integers are valid (non-error) results.

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