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

Rich Shepard rshepard at appl-ecosys.com
Sun May 28 14:17:51 EDT 2000


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.

  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.

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'



More information about the grass-dev mailing list