[GRASS-dev] adding lib_arraystats

[Glynn Clements]

Paul Kelly wrote:

> > I'm happy that I've been able to launch a discussion about linking R into 
> > GRASS, but could someone tell me if I can check the code into svn ?
> 
> I can't presume to say anything other than if you feel happy the quality 
> and functionality is up to inclusion in GRASS, go ahead - but if you'd 
> like a couple of comments on it here goes:
> 
> the typedef STATS looks a little weird to me, (a) because STATS on its own 
> is a very generic sounding name and (b) because in general typedefs are 
> used very little in GRASS (for one thing they confuse me...) I'd suggest 
> something along the lines of "struct GASTATS", avoiding the typedef.

Agreed. GRASS normally uses structure tags rather than typedefs.

> EXIT_SUCCESS used as a function exit status looks a bit strange to me too- 
> IIUC this is defined in stdlib.h and intended for programs to return a 
> status code to the enviroment when they exit, not really for internal use 
> by functions.

Good point. EXIT_SUCCESS and EXIT_FAILURE are (technically)
platform-specific. So any code which called the function would need to
check against those specific constants (you can't assume that success
is zero and failure is non-zero).

FWIW, I suggest C truth values for functions which don't return
anything other than success or failure, with true (non-zero) for
success and false (zero) for failure. Tests would be written as:

	if (foo()) { /* if foo succeeded */ }
or:
	if (!foo()) { /* if foo failed */ }

Reversing the sense of the result (i.e. zero for success) means that
you would have a different convention for int results than for
pointers. Functions which return pointers almost[1] invariably return
NULL (i.e. zero) for failure.

[1] The notable exception is mmap(), which returns ((void *) -1) for
failure. I'm sure they had a reason, but I have absolutely no clue as
to what that reason might be.

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