>>>>> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>>> if (color <= 0) return 0;
>> BTW, is it a GRASS convention to use 0 to indicate failure?
>> Standard C library functions tend to use -1 for failure, while using
>> non-negative values to indicate success.
> The GRASS convention is to use a different convention for each
> function ;)
> More seriously: functions which only return a success/failure
> indication typically (but not always) return 1 for success and 0 for
> failure, so that conditionals read naturally, i.e. "if (foo(...))"
> means "if it succeeds" and "if (!foo(...))" means "if it fails".
> Functions which normally return a non-negative integer normally
> return a negative integer to indicate failure.
ACK, thanks.
> Functions which return 0 for success should ideally be tested using
> "if (foo(...) == 0)" rather than "if (!foo(...))", as the use of "!"
> connotes a negative (i.e. failure).
I completely agree with this point.
>> Also, it seems feasible to set `errno' in the library functions like
>> this. Do I understand correctly that it isn't done (with any
>> regularity) in GRASS?
> AFAIK, GRASS itself never sets errno.
But, IIUC, it doesn't prevent `errno' from being set by the
standard library functions it calls?
Setting `errno' would make sense should there be a demand to use
the standard C means of error reporting in the GRASS code. And
I can see a point in it.
[...]
>> With the `if (X != 0)' guards, the function may be used to query
>> whether the given color index exists, while not asking for its
>> components to be returned, like:
>> if (D_color_number_to_RGB (INDEX, 0, 0, 0) < 0) {
>> /* color INDEX doesn't exist */
>> }
> That makes sense, although I would omit the "!= 0", and just use e.g.
> "if (r) ...". Generally, I prefer "if (x)" and "if (!x)" if zero/NULL
> is a false/unset/etc indicator.
Oh, and I prefer both the ``success'' and the ``null'' tests to
be written explicitly. But I see a little difference anyway.
>> If `struct color_rgb' is a ``public'' data type, then it might be
>> appropriate to code this function as:
> The problem is that we have both color_rgb (colors.h) and RGBA_Color
> (gis.h) structures, and we should deprecate one of them (probably
> color_rgb).
Although I know no details, having two similar facilities
usually implies having the code base doubled, with only a slight
increase of functionality.
As for a generic color facility, I'd suggest looking at the
following for the inspiration:
http://www-swiss.ai.mit.edu/~jaffer/slib_5#Color
http://www-swiss.ai.mit.edu/~jaffer/Color/Color-Scheme
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
