I was writing a code to swap the elements of 2 arrays, my colleague wrote the function as a pointer to integer return value and in main he didn't receive the returning pointer, yet the code worked perfectly, why is this possible?, I will try to include some code below:
int * Swap (int a_size,int *a,int b_size,int *b){
int i;
int temp;
for(i=0;i<b_size;i++){
temp=a[i];
a[i]=b[i];
b[i]=temp;
}
}
I guess there are sort of two questions here:
Let's examine these in turn.
First, if a function is declared to return a value (or not), how wrong is it to not return a value (or to return a value)?
There are four cases:
void, function does not return value: this is obviously good and proper.void, function does return value: this is obviously an error, and the compiler will emit an error message and halt compilation.} without ever having a return statement, versus the case where it has an explicit return; statement without a value.)That might answer your question, but if not, let's move on to my second question: if a function returns a value (or not), how wrong is it for the caller not to use the value (or to use the value)?
Again, there are four cases:
void, caller does not use return value: this is obviously good and proper.void, caller does use return value: this is obviously an error, and the compiler will emit an error message and halt compilation.For a function like sqrt, whose sole function is to compute and return a value, it would obviously be very strange to not use the return value. For example, if you write
sqrt(100);
alone on a line, you're asking to compute the square root of 100, and then throwing away the return value. This is not an error, but a good compiler will probably warn about it, because it's probably not what you want.
There are other functions that return a value, that you might not care about. For example, it's not well known that the venerable printf function returns a value: the number of characters printed. But printf is not a function whose sole function is to compute and return a value; printf also does something interesting off to the side: it prints stuff. So if you call
printf("Hello, world!\n");
but if you throw away the return value, that's fine, almost no one would object to that. (Theoretically there's a chance that printf might fail, due to some kind of an i/o error, and return -1 to try to tell you this, but most programs don't care about this, and in the grand scheme of things that's not a problem.)
Finally, there are programs that return a value, that you might not think you care about, but that you probably should care about. Consider this fragment:
int i;
printf("enter an integer:\n");
scanf("%d", &i);
printf("you typed %d\n, i);
Here, the problem is that if the user types something like "no, I won't", scanf will be unable to read an integer as requested by %d, and it will return 0 to say that it performed no conversion, but the program won't notice, and since i is an uninitialized value, it's hard to see what the program might print.
If we think about this carefully, we see that there might be sort of a "hidden" attribute of functions, namely: "How okay is it for the caller to ignore the return value?" printf is a function that returns int, but it's usually (in all but the most paranoid programs) okay to ignore the return value. But scanf is a function that returns int where, as we've just seen, it's not a good idea to ignore the return value (although lots of programmers do). And sqrt is a function returning double, where it's almost certainly an error not to use the return value. So if a compiler decides to help you out by warning you when you forget to use a function's return value, how does it avoid spamming you with warnings every time you call printf? And the answer is that such a compiler has to invent a special way to implement that property -- a property not defined by the C language, which is why I called it "hidden" -- that specifies whether or not the warning is appropriate.
Also -- and this gets down to the meat of your question as asked -- there's a higher-order question that sort of combines the two top-level questions I've been exploring: If a function is declared as returning a value, but does not return a value, what happens if the caller does/doesn't try to use the returned value?
And the answer is that if a function is declared as returning a value, but it doesn't actually return a value, but the caller doesn't try to use the return value, that's fine -- although this might seem like kind of a dicey situation! And on the other hand, if the caller does try to use the value that wasn't returned, that's obviously a bad situation. As far as the C Standard is concerned, it falls into the dreaded category of undefined behavior, and there's a pretty good reason for this: deciding whether it's actually a problem is a hard, almost impossible problem. If a function is declared as returning a value, and if it sometimes doesn't return a value, and if the caller sometimes doesn't try to use the returned non-value, deciding whether it's actually a problem would theoretically requiring (a) examining the code for both the function and its caller and (b) deciding under which circumstances the function does or doesn't return a value. Both of these subproblems are basically impossible to solve. C supports separate compilation, so in the general case a compiler won;t be able to inspect both the function and its caller at once. And solving subproblem (b) is basically the halting problem. So it's up to you, the programmer, to keep things straight in this case: the compiler can't be required to issue an error if you try to use the value that wasn't returned by a function declared as if it returned one.
In the end, though, the Swap() function you posted could probably an example of the "don't care" case. It's defined as returning int *, but it doesn't actually return a value, but the caller doesn't try to use it, so it's okay. But this is potentially quite confusing and error-prone, so I would suggest that it would be much better to either (a) have it actually return a value or (b) redeclare it as returning void.
The C standard does not require a function declared with a non-void return type to return a value. It is not, by itself, undefined behavior for such a function not to return a value.
It is undefined behavior if the caller attempts to use the value of a function that did not return a value. C 2018 6.9.1 12 says:
Unless otherwise specified, if the
}that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.
(It is “otherwise specified” for main: In a hosted environment, if the return type of main is int and it reaches the } that terminates its body, it returns zero, per C 2018 5.1.2.2.3 1.)
In most cases, it is good practice for a function declared with a non-void return type to return a value, and compilers may warn if they do not. However, there are situations in which a function may be intentionally designed not to return a value in all cases. For example:
typedef enum { Get, Set } CommandType;
int DoCommand(CommandType Command, int Value)
{
switch (Command)
{
command Get:
return SavedValue;
command Set:
SavedValue = Value;
break;
}
}
This is a very simplified abstracted example—with simple situations, we might want to separate this routine into two routines, one to set and one to get. But in more complicated software, it might make sense to wrap these and other “commands” that operate on various objects (not shown) into a single command-and-control routine which sometimes returns a value and sometimes does not.
In order to write correct C programs, one should always indicate the correct return type of the function. In case a function does not return any value, a "special" return type void is used.
Example function that returns an int:
int add(int a, int b) {
return a + b;
}
Example function that returns nothing:
void swap(int* a, int* b) {
int temp = *a;
*a = *b;
*b = temp;
}
You can ignore the return value of a function if you don't need it:
void test(void) {
int x = add(3, 5); // correct, we're using the return value of add()
add(1, 2); // also correct, we're just ignoring the return value of add()
(void) add(1, 2); // more correct, this is just like previous line, but we're making it obvious to the reader that we are explicitly ignoring the return value, and it is not a mistake
}
EDIT: in order to make my answer more useful, I will add some examples of what SHOULD NOT be done in C.
Example 1:
// WRONG, because we defined neg() to return an int, but we're not returning it
// NOTE: this is wrong even if we ignore the return value of neg()
int neg(int* a) {
*a = -(*a);
}
// POSSIBLE CORRECT ALTERNATIVE
void neg(int* a) {
*a = -(*a);
}
// ANOTHER POSSIBLE CORRECT ALTERNATIVE
int neg(int* a) {
*a = -(*a);
return *a;
}
Example 2:
// WRONG, because we defined foo() to return nothing, but we're actually returning an int
void foo(int a) {
return a;
}
// CORRECT ALTERNATIVE
int foo(int a) {
return a;
}
Example 3:
// CORRECT
void foo(int a, int b) {
if (a == 0) {
return; // we're returning early from the function (and we're returning nothing, of course, since function is void)
}
printf("%d %d\n", a, b);
return; // this is really not needed and it is implicit in void functions: when they reach the end, they return nothing
}
// WRONG
int bar(int a, int b) {
if (a == 0) {
return; // WRONG, we must return an int
}
int x = foo(1, 2); // WRONG: foo() returns nothing (i.e.: void), and we cannot therefore use the return value of foo()
// WRONG: reached end of function, but we never returned an int
}
Example 4:
void test(void) {
printf("Hello, I'm ignoring your return value.\n"); // CORRECT, printf() is a standard function that returns the number of characters written (returned as an int), and if we don't need this information, we can just ignore the returning value
malloc(500); // WRONG, malloc() is a standard function defined to return a pointer, and it is one of many functions that we should never ignore the return value of
// The difference between printf() and malloc() must be learned from the docs: there we can find out that printf()'s return value can be safely ignored, while malloc()'s cannot
}
EDIT 2: in my answer the words CORRECT and WRONG are not always used to say "it is correct/wrong according to the ISO C standard", but sometimes (as in the example of malloc() vs printf()) they mean "it is correct/wrong according to good programming practices"
Yes. Always do a clean return from any non-void function.
Otherwise the consequences are
