Return Value Practice

L

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

Ian Pilcher

Lyle said:
Hello,

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

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

CBFalconer

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

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

Default User

Lyle said:
Hello,

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

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
 
A

Alan Balmer

Hello,

In the case of returning an integer from a function to notify success or
error which does 0 customarily signify? For example:
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.
 
J

Jason Curl

Alan said:
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.

Are the constants

EXIT_SUCCESS
EXIT_FAILURE

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

Eric Sosman

Jason said:
Are the constants

EXIT_SUCCESS
EXIT_FAILURE

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

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

Lyle Fetterly

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

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

Chris Croughton

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.

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_WRITEFAIL, ...).

Chris C
 
K

Keith Thompson

Lyle Fetterly said:
EXIT_SUCCESS / EXIT_FAILURE - yes, standard and intuitive. Thanks for
pointing them out.

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

Default User

Keith said:
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.)

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
 
C

CBFalconer

Chris said:
.... snip ...

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.

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

Lawrence Kirby

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.

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top