Thread: Int return from functions - 0 or 1 ?

Usually things can only succeed in one way and fail in multiple ways. In these cases 0 is used to indicate success and any other number to indicate various error conditions.

In your upper example, if you are really interested in success, that's what you should test against (thatWorked == 0). And if your functions only "fail" in one way it would make more sense to return 1 for success and 0 for error.

In the end you'll have two kinds of functions: ones that return true or false and ones that provide more information than that. I mean, something like OpenDatabase clearly might fail in several ways whereas IsPrime is the kind of function that is supposed to return a boolean.

Originally Posted by trillianjedi

Most of the standard C system calls I use return 0 on success, -1 on failure and sometimes an arbitrary positive int as information to the caller.

Normally there are more ways for something to fail than for it to succeed. Typical approach is that of HRESULTs:
0 == SUCCESS
< 0 == FAILED
> 0 = SUCCEEDED with extra info (Normally very few of these exist, only S_FALSE that I'm aware of)
This is a good approach because comparisons with zero are usually simpler for the CPU.

You could also do:

Code:

if ( succes(foo()) )
{
   printf("error");
   exit(1);
}

And have foo return something other than 0 or 1.

Originally Posted by C_ntua

The only good thing about 0 for success is using:

Code:

if (foo()) {
   printf("error");
   exit(1);
}

if 1 for success then you would need if (!foo()). An extra ! :P.
But yeah, having the obvious 0 for failure is more important. You can use 0 and nagatives for failure, positives for success.
Also the above code is kind of "ugly". I mean at a first glance it is misleads you to understand "if foo() succeeds then print error and exit".
So just for these two reasons I would personally prefer 1 for success.

That's misleading. There is no point in returning an error code, if you don't output what it is. The code that you have up there is pretty pointless. Normally, I'd write:

Code:

int error_code = foo();
if (error_code) {
  printf ("Error received from foo. Error code = %d\n", error_code);
  return 1;
}
/* Do something else */
return 0;

That way rcode returns true when there is an error, making the whole interface nice and neat again. Besides which, you should always print out the error code that you receive.

QuantumPete

Originally Posted by C_ntua

A programming language should try to prevent users from writing something misleading

A programming language should do the job it was designed for. C was not designed to have type-safety, so it doesn't prevent users from doing horrible things with casting. You can't say a language is good or bad just because it has or hasn't got a certain feature.

QuantumPete

Originally Posted by C_ntua

For me it would be better if they had decided to put 1 for success. That is just an opinion.

Well, no one's stopping you. It certainly isn't embedded in the language, so we're free to do what we want.

We still use it because it still has some advantages and personally I prefer it from the rest.

I don't see how ANYONE can like C over other higher-level languages such as C++. C++, being built upon C, does everything the C way and much more without sacrificing anything. Indeed, I would say that C++ can be as fast or faster than C.

As discussed, there are several possible scenarios. Windows and Unix/Linux have slightly differnet strategies, and neither is entirely consistent. The C library has a further different (and inconsistent) standard.

The reason for the inconsistency is generally that we want to use the return value for two purposes:
1. Indicate success/failure.
2. Pass some sort of data back to the program itself.

An example would be fread, which returns a zero or positive value on "success", as it returns the number of items read, where zero means that it was not possible to read any more data items. A negative value (typically -1, EOF) is returned on an attempt to read "past the end of file", but also on other failures (invalid file-pointer, file has been closed before reading, etc).

The Unix/Linux OS API function read() follows the same type of pattern: positive value -> successfully read x bytes.

On the other hand, the Windows API ReadFile() returns a BOOLEAN that is TRUE (non-zero) for success and FALSE (zero) for failure.

It is good if a group of functions (at the very least) follow a systematic pattern, and if all functions are following a pattern, it's even easier to write code tha tuses those functions.

--
Mats

Originally Posted by C_ntua

That is something the guys that developed the functions decided.

Well that is not strictly true. C behaves the same way as UNIX, where a return code of 0 signals success. I suppose it was only natural to continue the same convention in C.
But you only want function to return 1 for success because C sees 1 as boolean TRUE and 0 as boolean FALSE. In effect this whole debate only arises, because C has no built-in boolean type and we have to make do with a number instead. We then impose an arbitrary booleanness on the numbers.
That, to me, is the bigger failing. Even FORTRAN has a "logical" type that can be used to return success or failure for a function.

QuantumPete