[GRASS5] Function return codes (a thread from the programmer's manual thread)

[Bernhard Reiter]

On Sun, May 28, 2000 at 11:17:51AM -0700, Rich Shepard wrote:
> On Sun, 28 May 2000, Andreas Lange wrote:

> > I think some programmers derived the return values from c stdio
> > functions, which return EOF (defined as -1) on error and 0 on success.
> > This is usual practice in c. 

> > The code of the libraries and modules mixes 0 (numerical zero) with NULL
> > (the null pointer), which i personally find confusing too. Some modules
> > use 0 (numerical zero) interchangebly with `\0` (string terminator),
> > which is also confusing. Many modules use -1, but mean EOF. Although
> > there are in most cases no compile or run-time errors with this, it is
> > not a good practice and i think everyone writing new code should be
> > encouraged to use this consistently. Yes, and there are many many
> > problematic typecasts or missing typecasts, so that gcc or a linter
> > complains about incompatible pointer types.
> 
>   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.

You cannot really establish a general rule, as there will always be
functions for which the return value is within -1 0 1 and others were
you really need -1 and 0 as vaild numbers. 

This depends on the type of the function, of course.
It just needs to be documented.

>   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.

I advise against this type of fix. As both types of functions exist, we
should document them very well. You need to read the docs anyway before
you can use a GRASS library function.

As Andreas pointed out there a quite a bunch of weaknesses in the code.
Grown out of several assumptions which do not generallx hold true today 
anymore.  (Like the equivalent of integer and a pointer.)

Some of them need to be fixed of course.
Just switching the sematics of the return values for some functions
around does not fall into the category that needs a fix.

>   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.

-- 
Professional Service around Free Software                (intevation.net)  
The FreeGIS Project				            (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 236 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20000529/8fb34182/attachment.bin