Let's say I have the following C code:
int return_one()
{
return 1;
}
int main(void)
{
return_one();
}
Within the main function, I call function return_one()
and ignore the return value. The compiler has no issue with me ignoring this value.
What is the logic as to why this okay? Was it an arbitrary design choice from the C creators? Or is there a practical reason for not requiring the calling function to use the return value?
CodePudding user response:
Yes C does easily allow you to ignore return values. If your function isn't one that will fail, or if the return won't tell you about an error, it can be ignored. It is however bad practice, and should be avoided.
The compiler will warn you if you ignore return values for some other functions like scanf since that function can fail easily.
CodePudding user response:
Because people don't care about a lot of return values, so why force them to use them?
A ton of standard C functions return values that are essentially never looked at. Think about all the C code you've ever looked at. Have you ever seen someone do anything with the return value from the printf
family of functions? Because they all have one, but you'd never know it to look at real world code. Would it be improved if every single call to printf
had to prefix it with an explicit "I don't care about the return value" bit of syntax (e.g. (void)
), because 99.99% of the time, you don't actually care how many bytes you printed, but printf
computes and returns it anyway? Basically, you're allowed to not use the return value because there's was no need to force you to do so, and it's often not needed.
CodePudding user response:
tl;dr: You can write code such that the return values are always relevant - in that case ignoring them would be a bug. However, some (particularly older) code does not work that way, there ignoring return values may be reasonable.
What is the logic as to why this okay? Was it an arbitrary design choice from the C creators?
It is not just a choice by the C creators, many other languages also allow this - as a matter of fact, I cannot think of a language where ignoring the return value is considered an error.
The practical motivation for this is mainly that the return value of a function is often used for reporting errors, or reporting details of what the function did. Sometimes, you are not interested in these details, so you ignore them. A common example of this is the C function printf
, which returns the number of characters printed. While this may sometimes be useful, it is usually not, so the return value of printf
is usually ignored.
This is arguably a bad design (either in your code, or in the function that returns stuff noone wants), but it is established practice, so C (like other languages) supports this.
Or is there a practical reason for not requiring the calling function to use the return value?
No, there is no practical reason for ignoring return values - unless you do not want them.
While the above is the historical practice, many people now consider ignoring return values a problem (or a symptom of a deeper problem):
- If the return value is for error reporting, ignoring it will work usually, but cause problems if there really is an error. This is now usually considered a bad idea.
- Generally, if you can ignore the return value, that means the function is causing side-effects (otherwise calling it would be pointless). Many people think that it is better to have functions only do one thing - either cause a side effect (and return nothing), or return a value (and have no side effects). The latter is often called a pure function (with the additional condition of the output only depending on the input). This separation makes it easier to understand software - and if you use it, ignoring a return value is necessarily a mistake, because functions returning a result do nothing else, so if you ignore the result, calling it is pointless.
So in other words: If you follow certain conventions, there should be no situation where you want to ignore return values, in that case ignoring them is usually a mistake. Without these conventions, there may be good reasons for ignoring them, so there's no general rule.