>>>>> Glynn Clements <[EMAIL PROTECTED]> writes:
>>> 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.
> I would rather have a separate grass_errno function (PROJ has
> pj_errno), so that failures originating at the OS level (e.g. ENOSPC
> or EPERM) can have the underlying cause determined.
Surely. I'd just ask not to ``if (errno == FOO) {
set_grass_errno_for_this_thread (BAR); }'', but rather just pass
`errno' to the caller untouched.
Iff the problem could be described completely by the `errno'
value, then the value of grass_errno () shouldn't be touched.
[...]
>> 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
> I'm inclined to think that supporting explicit colour spaces is
> overkill for GRASS.
[...]
I'm going to agree for just now.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
