Return Value Practice

[Lyle Fetterly]

Hello,

In the case of returning an integer from a function to notify success or
error which does 0 customarily signify? For example:

int chk( int c ) {
...
}

int fn( int c ) {
if( chk( c ) == 0 ) {
printf( "Success\n" );
} else {
printf( "Error\n" );
}
return c;
}

Looking at chk( c ) == 0 and the flow of the if statement, to be in line
with common practice, is the statement correct as is? Or should it become
chk( c ) != 0?

Thanks - Lyle.

[Ian Pilcher]

Re: Return Value Practice

Lyle Fetterly wrote:[color=blue]
> Hello,
>
> In the case of returning an integer from a function to notify success or
> error which does 0 customarily signify? For example:
>[/color]

To the extent that there is a custom, 0 usually signifies success. If
you're unfamiliar with a particular library function, however, always
read the documentation before assuming anything.

--
=============== =============== =============== =============== ============
Ian Pilcher i.pilcher@comca st.net
=============== =============== =============== =============== ============

[CBFalconer]

Re: Return Value Practice

Lyle Fetterly wrote:[color=blue]
>
> In the case of returning an integer from a function to notify
> success or error which does 0 customarily signify? For example:[/color]

Since success is the lack of errors, and there can be multiple
forms and classes of error, it is practical to signal success with
a zero, and error details with non-zero. Assuming no other
constrictions on the returned value.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Default User]

Re: Return Value Practice


Lyle Fetterly wrote:[color=blue]
> Hello,
>
> In the case of returning an integer from a function to notify success[/color]
or[color=blue]
> error which does 0 customarily signify?[/color]

As the others have mentioned, it's typically success, basically meaning
no error code. It's also in line with the return from main(), where 0
is the same as EXIT_SUCCESS (which is not to say that EXIT_SUCCESS == 0
necessarily).




Brian

[Alan Balmer]

Re: Return Value Practice

On Mon, 4 Apr 2005 11:51:01 -0500, "Lyle Fetterly" <lef204@mts.net >
wrote:
[color=blue]
>Hello,
>
>In the case of returning an integer from a function to notify success or
>error which does 0 customarily signify? For example:
>[/color]
Often, 0 is success, simply because there may be more than one failure
return. If you can have return values of 0 through 7, it seems
unnatural to pick 4 to mean success.

OTOH, in cases where the return is logical (true/false) instead of
numeric, you might well want 0 to mean "fail" and anything else to
mean "succeed." Look at the ctype functions, for example - isdigit()
returns 0 if its argument "fails" the test.

Write for readability.
[color=blue]
>int chk( int c ) {
> ...
>}
>
>int fn( int c ) {
> if( chk( c ) == 0 ) {
> printf( "Success\n" );
> } else {
> printf( "Error\n" );
> }
> return c;
>}
>
>Looking at chk( c ) == 0 and the flow of the if statement, to be in line
>with common practice, is the statement correct as is? Or should it become
>chk( c ) != 0?
>
>Thanks - Lyle.
>[/color]

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Jason Curl]

Re: Return Value Practice

Alan Balmer wrote:[color=blue]
> Often, 0 is success, simply because there may be more than one failure
> return. If you can have return values of 0 through 7, it seems
> unnatural to pick 4 to mean success.
>
> OTOH, in cases where the return is logical (true/false) instead of
> numeric, you might well want 0 to mean "fail" and anything else to
> mean "succeed." Look at the ctype functions, for example - isdigit()
> returns 0 if its argument "fails" the test.
>
> Write for readability.[/color]

Are the constants

EXIT_SUCCESS
EXIT_FAILURE

useful here, when <stdlib.h> is included?

[Eric Sosman]

Re: Return Value Practice



Jason Curl wrote:[color=blue]
> Alan Balmer wrote:
>[color=green]
>>Often, 0 is success, simply because there may be more than one failure
>>return. If you can have return values of 0 through 7, it seems
>>unnatural to pick 4 to mean success.
>>
>>OTOH, in cases where the return is logical (true/false) instead of
>>numeric, you might well want 0 to mean "fail" and anything else to
>>mean "succeed." Look at the ctype functions, for example - isdigit()
>>returns 0 if its argument "fails" the test.
>>
>>Write for readability.[/color]
>
>
> Are the constants
>
> EXIT_SUCCESS
> EXIT_FAILURE
>
> useful here, when <stdlib.h> is included?[/color]

They'll work on any "decent" implementation, but it's
probably better to avoid them for this use. The gaping
hole is that the two macros might expand to the same value
on an implementation where there's no way to communicate an
exit status to the environment. Also, if you're writing
code that could be useful in a free-standing environment,
keep in mind that <stdlib.h> might not exist at all.

--
Eric.Sosman@sun .com

[Lyle Fetterly]

Re: Return Value Practice

> As the others have mentioned, it's typically success, basically meaning[color=blue]
> no error code. It's also in line with the return from main(), where 0
> is the same as EXIT_SUCCESS (which is not to say that EXIT_SUCCESS == 0
> necessarily).[/color]

EXIT_SUCCESS / EXIT_FAILURE - yes, standard and intuitive. Thanks for
pointing them out.

[Chris Croughton]

Re: Return Value Practice

On Tue, 05 Apr 2005 10:09:04 -0400, Eric Sosman
<eric.sosman@su n.com> wrote:
[color=blue]
> Jason Curl wrote:[color=green]
>>
>> Are the constants
>>
>> EXIT_SUCCESS
>> EXIT_FAILURE
>>
>> useful here, when <stdlib.h> is included?[/color]
>
> They'll work on any "decent" implementation, but it's
> probably better to avoid them for this use. The gaping
> hole is that the two macros might expand to the same value
> on an implementation where there's no way to communicate an
> exit status to the environment. Also, if you're writing
> code that could be useful in a free-standing environment,
> keep in mind that <stdlib.h> might not exist at all.[/color]

You would also need to test for them explicitly, because EXIT_SUCCESS is
not necessarily defined as zero. They are only designed as values to be
passed as the status to the exit() function:

If the value of status is zero or EXIT_SUCCESS, an implementation-
defined form of the status successful termination is returned. If the
value of status is EXIT_FAILURE, an implementation-defined form of
the status unsuccessful termination is returned. Otherwise the status
returned is implementation-defined.

Thus either zero or EXIT_SUCCESS is treated by exit() as a success
result but there is nothing to say that EXIT_SUCCESS has to be zero.

I would generally go with one of the following:

0 is OK, -1 is failure (and possibly anything else is a qualified
success). Used by the file I/O functions.

0 is false, 1 (or anything else) is true, used by the ctype.h
functions and macros.

-1, 0, +1 as comparison results, used by strcmp() etc.

An enumerated integer type (or possibly macros), usually in a header
file, for the exit conditions (MYFUNC_OK, MYFUNC_READFAIL ,
MYFUNC_WRITEFAI L, ...).

Chris C

[Keith Thompson]

Re: Return Value Practice

"Lyle Fetterly" <lef204@mts.net > writes:[color=blue][color=green]
>> As the others have mentioned, it's typically success, basically meaning
>> no error code. It's also in line with the return from main(), where 0
>> is the same as EXIT_SUCCESS (which is not to say that EXIT_SUCCESS == 0
>> necessarily).[/color]
>
> EXIT_SUCCESS / EXIT_FAILURE - yes, standard and intuitive. Thanks for
> pointing them out.[/color]

For various reasons, it's not a good idea to use EXIT_SUCCESS and
EXIT_FAILURE as return codes for functions other than main(). It's
too easy to write code that assumes EXIT_SUCCESS is 0 and EXIT_FAILURE
is 1; such errors won't be found until the code is ported to a system
that uses different values. It's also conceivable that they could
have the same value. (Eric Sosman already pointed out some of this.)

There's no universal convention for return codes for functions. For
some functions, it makes sense to use 0 for "success" and non-zero
(typically -1) for "failure". Other functions, like the ones in
<ctype.h>, return a true/false result rather than a success/failure
result. Yet others might have a number of possible results, perhaps
encoded in an enum type.

Study the standard library and use its conventions where appropriate
(and not where they're not). Pick a consistent set of conventions for
a library of functions and stick with it. Make sure the caller and
callee use the same convention.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Default User]

Re: Return Value Practice


Keith Thompson wrote:[color=blue]
> "Lyle Fetterly" <lef204@mts.net > writes:[color=green][color=darkred]
> >> As the others have mentioned, it's typically success, basically[/color][/color][/color]
meaning[color=blue][color=green][color=darkred]
> >> no error code. It's also in line with the return from main(),[/color][/color][/color]
where 0[color=blue][color=green][color=darkred]
> >> is the same as EXIT_SUCCESS (which is not to say that EXIT_SUCCESS[/color][/color][/color]
== 0[color=blue][color=green][color=darkred]
> >> necessarily).[/color]
> >
> > EXIT_SUCCESS / EXIT_FAILURE - yes, standard and intuitive. Thanks[/color][/color]
for[color=blue][color=green]
> > pointing them out.[/color]
>
> For various reasons, it's not a good idea to use EXIT_SUCCESS and
> EXIT_FAILURE as return codes for functions other than main(). It's
> too easy to write code that assumes EXIT_SUCCESS is 0 and[/color]
EXIT_FAILURE[color=blue]
> is 1; such errors won't be found until the code is ported to a system
> that uses different values. It's also conceivable that they could
> have the same value. (Eric Sosman already pointed out some of this.)[/color]

It should noted that I (the author the bit at the very top) was not
advocating the use of EXIT_SUCCESS as a return code for user-defined
functions, but merely showing that a return of 0 is one of the returns
from main() indicating success, hence is common enough in that context.





Brian

[CBFalconer]

Re: Return Value Practice

Chris Croughton wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> I would generally go with one of the following:
>
> 0 is OK, -1 is failure (and possibly anything else is a qualified
> success). Used by the file I/O functions.[/color]

Most file functions return EOF for failure, which is always
negative, and often is -1, but need not be.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Lawrence Kirby]

Re: Return Value Practice

On Mon, 04 Apr 2005 18:49:05 +0000, CBFalconer wrote:
[color=blue]
> Lyle Fetterly wrote:[color=green]
>>
>> In the case of returning an integer from a function to notify
>> success or error which does 0 customarily signify? For example:[/color]
>
> Since success is the lack of errors, and there can be multiple
> forms and classes of error, it is practical to signal success with
> a zero, and error details with non-zero. Assuming no other
> constrictions on the returned value.[/color]

But consider a funciton like getc(). It has many succcessful return values
and one vailure value. OK that failure value isn't zero (zero is a
valid success value) but I'm talking about the principle. Also consider
the relationship with pointers - 0 is a null pointer constant and a null
pointer return typically indicates a failure.

I think the point here is that there is no firm convention for this, it
can work perfectly well either way. All I would suggest is that if you are
creating a family of functions then it can help to be consistent within
the family.

Lawrence