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

[Robert Lagacé]

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.
> 
> Andreas,
> 
>   You are, of course, correct. It's been a couple of years (or more) since I
> did any coding.
> 
> > 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.
>

As a user programmer, I prefer clean definition and API.
 
>   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.
> 
>   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.
>

It is my feeling resulting from my experience.
 
> Rich
> 
> Dr. Richard B. Shepard, President
> 
>                        Applied Ecosystem Services, Inc. (TM)
>               Making environmentally-responsible mining happen. (SM)
>                        --------------------------------
>             2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
>  + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

-- 
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace at grr.ulaval.ca

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'