Simple question: is false 0 or non-zero ?

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, please don't laugh at me ...
I think I am going to mix something.

I am not sure: Should a function return in case of success 0 or non-zero ?

What is more efficient ?

Can I write c-functions as bool in avr-gcc ?

I program like a man:
COPY CON: > firmware.hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In C, false is 0, true in non-zero. Yes, avr-gcc is a C compiler for AVR microcontrollers.

As for returning 0 or non-zero for indicate success, different API's have difference semantics. Personally I use non-zero to mean success. I think a lot of C libraries use 0 to indicate success so that they can return different non-zero codes as different failure codes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-1 can often be a popular choice to indicate error return from functions that usually return a positive integer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I normally return a 0 for success or non-zero for failure. Be sure not to waste stack space by returning an int when a char would work just fine!

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Generally I return 1 for TRUE and 0 for FALSE if I think I'll be using the function in an if statement. If I'm returning counts then 1 or more is good (SUCCESS) and 0 may be bad but -1 (FAILURE) is very bad. Use defines can make things much easier.

Neil Cherry
Linux Home Automation
Author: Linux Smart Homes For Dummies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I usually return a boolean result from fuctions, so FALSE=0. However, occasionally I return 0 for success so that failure can indicate the cause of the problem.

As far as efficiency is concerned, I guess there is usually no difference. The overhead of non-inlined calls is probably much higher than any savings gained by tweaking the return value semantics.

As usual, in a critical piece of code, testing the effects of either approach may be a good idea.

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can I write c-functions as bool in avr-gcc ?

Yes, but you will need to include .

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jevin wrote:
Yes, I normally return a 0 for success or non-zero for failure. Be sure not to waste stack space by returning an int when a char would work just fine!

Take a look at the assembly output (for GCC), I think you'll find that an int is returned, even if the type is char.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
Take a look at the assembly output (for GCC), I think you'll find that an int is returned, even if the type is char.
That's right, glitch. And, I'm sure that you've seen in IAR it is not. (I think ImageCraft can also return an 8-bit value).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all for the statements.

I program like a man:
COPY CON: > firmware.hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cpluscon wrote:
I usually return a boolean result from fuctions, so FALSE=0. However, occasionally I return 0 for success so that failure can indicate the cause of the problem.

It would be nice if life were simple. I find myself wanting to use one scheme, and then shortly afterwards the other, depending on how the resulting code is laid out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As my projetc is growing, i have mixed something. So, some functions are returnig 0 for success, some non-zero which makes it quite hard to keep anything in mind!

Especially these while(function_with_return()) {};- constructions are dicfficult to manage !

I program like a man:
COPY CON: > firmware.hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not standardise it across the project with a common header file containing something like:

typedef enum {
  FUNCTION_SUCCESS = 1
  FUNCTION_FAIL = 0
} function_return_t;

Then just fill in '0' or '1' as you choose. Functions then have:

function_return_t my_fn(parms) {
  function_return_t retval;

  retval = FUNCTION_SUCCESS;
  if (something_went_wrong) {
    retval = FUNCTION_FAIL;
  }
  return retval;
}

For your while() example do not rely on a definite 0/1 value (in case you ever choose to change the enum definition) but instead alway code either:

while(function_with_return() == FUNCTION_SUCCESS) {
while(function_with_return() != FUNCTION_SUCCESS) {
while(function_with_return() == FUNCTION_FAIL) {
while(function_with_return() != FUNCTION_FAIL) {

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Geoff wrote:
I find myself wanting to use one scheme, and then shortly afterwards the other, depending on how the resulting code is laid out.
I think we programmers used to be somewhat embarassed by this. But now we accept it as reality and call it "refactoring".
clawson wrote:

while(function_with_return() == FUNCTION_SUCCESS)

Often functions return information that don't map well to success/failure:

if (list.IsSorted()==TRUE)
    return;
list.Sort();

These are probably elements of individual programming style, and I use any/all as I see fit. (No strict rules.)

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well clearly, there wouldn't be much point implementing a strlen(), for example, that only returns SUCCESS/FAIL - but I thought the question concerned just those that did?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Too-shay.

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cpluscon wrote:
Too-shay.

Are you implying that Cliff is overly shay? :D

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

drnicolas wrote:
Sorry, please don't laugh at me ...
I think I am going to mix something.

I am not sure: Should a function return in case of success 0 or non-zero ?

As others have been telling you: Do what works well and wrapping your brain around it is part of working well.

Suppose function emma's normal purpose is to return a value.
Success would be indicated by returning a value in range.
Failure and perhaps the kind of failure would be indicated by an out of range value.
For example, strlen might return -1 if you
pass it a null pointer and -2 if it reaches
the end of memory without finding a null byte.

Suppose when function fred fails,
you want more information and when
it succeeds, you don't.
In that case, there should be a single return
code for success and others for failure.
Especially on unix platforms,
there is a tradition that the single return code be 0.
In C, it is the unique integer representation of false.
C has no unique integer representation of true.

Suppose when function greg succeeds,
you want more information and when if fails,
you don't.
In that case, failure should get the unique return code.
You will probably want greg's code for failure
to be different from fred's code for success.

The case where success or failure is all the information
you need could be treated as fred or greg.
If greg returns a different code for
failure from the one fred returns for success,
it can be treated as fred and greg.

Suppose you will want more information regardless of whether function hank succeeds or fails.
In that case, I'd recommend using strictly positive
values for success and negative values for failure.

Moderation in all things. -- ancient proverb