[GRASS-dev] lib fn to convert int color number to RGB values?

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> 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