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

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

[...]

 >>> The GRASS libraries are fundamentally designed to be used in
 >>> "one-shot" modules. Errors are handled by printing a message then
 >>> exiting. Variables are either initialised at startup from the .data
 >>> and .bss segments or are initialised upon first use. Memory doesn't
 >>> get explicitly de-allocated, as the operating system will do that
 >>> when the module terminates.

 >> Thanks for the clarification, but isn't the main question in whether
 >> there's any interest for it to be changed?

 > Oh, someone was to suddently turn up with a re-factored version where
 > all library functions behaved as desired and all modules had been
 > re-written accordingly, I'm sure that everyone would be happy.

 > [Assuming that you achieve this without significantly increasing the
 > job of writing modules. Minimising the effort involved in writing
 > modules takes precedence over most other considerations.]

	Yes.

[...]

 > The main problem here is that you would need to re-write all of the
 > lower-level functions to return (which means that they need to
 > perform clean-up in the event of an error), with the non-returning
 > versions implemented as a thin veneer at the top level.

	Yes, most probably.

 > I'm assuming that you're willing to at least leave malloc() errors as
 > fatal, otherwise you will have to re-write almost everything.

	I've already noticed that.  I don't feel that a change like this
	one is going to become feasible in any near future.

 > What about low-level I/O errors (EIO, ENOSPC, EPERM etc)? If e.g. EIO
 > while reading $GISRC needs to be propagated up to the caller, any
 > function which ends up calling G_getenv() would need to be
 > re-written, and that's almost as big an issue as malloc()
 > errors. Similar issues exist for WIND, VAR and PROJ_INFO, and
 > possibly for some map elements.

	I haven't yet looked at the code for these.  Most probably
	you're right.

[...]

 >> BTW, shouldn't G_find_cell () be marked as ``deprecated'' in
 >> `include/gisdefs.h' (if the compiler permits it), so that a warning
 >> will be issued for each its use?

 > There is a valid use for it, i.e. if you specifically want qualified
 > names to be split into map and mapset parts.

 > For 7.x, I would like to dispense with those functions altogether for
 > most modules. I.e. G_open_cell_old() etc would simply take the
 > (possibly qualified) name as an argument. Most modules wouldn't need
 > to know anything about mapsets; they would just pass the the value of
 > the ->answer field from the Option structure directly to the libgis
 > functions.

 > Most library functions would behave likewise, passing map names
 > around without needing to know the details. Only the lowest-level
 > functions which directly access files (e.g. G_{open,fopen}_*) would
 > need to decompose map names.

	Oh, but that sounds like a... rewrite!

	... And I'm pretty sure that such a change will bring clarity
	upon both the library interface and its callers.