Hi Rich,
Rich Shepard wrote:
This seems like a good time to switch to a consistent system. Zero could
represent success, -1 represent failure (for whatever reason), and other
return codes could be tested in context. That is, if a file handle is to be
returned, then that's what the int represents. If you are trying to open a
file, then only 0 and -1 are possible return options.
I think there will be no overall consistent system. The return values
used now are consistent within the system used. There are functions
which use an int retval only for error handling (returning 0 on error, 1
on success), others use int retval to return an index or filedescriptor
(returning neg. val. on error, pos. fd/index on succes), and still
others use the described system from stdin. You can not simply change
the semantics of these functions without a complete re-design of the
library.
As Bernhard said, this should simply be documented. The only functions
that could be changed with reasonable effort are those that return 0 on
success and 1 on error. I do not know if such functions exist.
If this is made the programming standard, it should be simple (but time
consuming) to fix one module at a time. Change the one, see what breaks, fix
the breaks, repeat.
This could evolve into an herculean effort. With ~ 300 Modules this
try-and-error approach seems to me very dangerous. There are other
methods to automate this.
Perhaps I'm out of line here, but sometimes -- quite often, in fact --
it's worth taking extra time to fix what was poorly done way back when
rather than trying to maintain the mess. Is this reasonable? After all,
there has been discussion of making other changes and cleaning up the system
in other areas. This should pay off handsomely in future revisions.
The GRASS code evolved partly from K&R (pre-ANSI-) c code. This is not a
matter of poor done coding, but of changing habits, changing culture,
changing compilers etc. , and i do not care if _working_ modules contain
not-so-clean code. I think that the clean-up should be done first on the
libraries and with second priority on the modules if someone works on
the code (for other reasons than cleaning).
Everything else is not realistic.
My main idea is to encourage everyone to stick to a consistent coding
style and to use a linter and gcc -Wall on the new code to prevent
future problems. Coding in an open software project has different
considerations than coding in an institution where the authors are
present all the time.
Now i will switch back to "cleaning up" the coordinate conversion
library,
cu,
Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
