function not returning a value

[Phil Carmody]

I'm not sure if you meant this, but your code, although written to
behave very differently than Nick's

It's not written to behave in any particular way at all, as it's a
contraint violation.

, will probably give the same
value on a lot of systems (since both printf and f return int, and
many systems use a single register for integer return values).

So in regards to Nick's comment about deserving to be shot, his
code could result in a very awful bug indeed! - one that only
appears after the code has been ported, perhaps many years later,
and even then might still exhibit no visible symptoms.

Nope, it should appear immediately upon seeing an inability to
compile without the obligatory diagnostic.

Phil

 

[Keith Thompson]

It's not written to behave in any particular way at all, as it's a
contraint violation.

Not in C90. (Of course it's horrible style in either C90 or C99.)

[snip]

 

[Nick]

Not in C90. (Of course it's horrible style in either C90 or C99.)

But does it (mine) exhibit undefined behaviour? I didn't know that a
bare return was a constraint violation in C99 (which is nice to know) but
feel free to remove the return at the end of the function as falling off
the end still works.

Horribleness not just conceded, but gloried in.

 

[Keith Thompson]

But does it (mine) exhibit undefined behaviour? I didn't know that a
bare return was a constraint violation in C99 (which is nice to know) but
feel free to remove the return at the end of the function as falling off
the end still works.

Horribleness not just conceded, but gloried in.

The function f by itself, even with the bare "return;" deleted and
allowing it to fall off the end, exhibits no behavior at all, since
it's never called. That's not as picky as it sounds; the manner in
which it's called is relevant here.

A simpler example that illustrates the same point:

int f(void)
{
puts("In f");
}

If the caller doesn't use the (nonexistent) result, there's no problem.

int main(void)
{
f();
return 0;
}

If the caller does attempt to use the result, as in:

int i = f();

then the behavior is undefined, by C99 6.9.1p12:

If the } that terminates a function is reached, and the value of
the function call is used by the caller, the behavior is
undefined.

and by C90 6.6.6.4:

If a return statement without an expression is executed, and the
value of the function call is used by the caller, the behavior
is undefined. Reaching the } that terminates a function is
equivalent to executing a return statement without an expression.

 

[Nick]

The function f by itself, even with the bare "return;" deleted and
allowing it to fall off the end, exhibits no behavior at all, since
it's never called. That's not as picky as it sounds; the manner in
which it's called is relevant here.

It did - I'd missed the fact that the main had got snipped, sorry!

The main function called f twice, like this:
printf("Result: %d\n",f(1));
f(0);

A simpler example that illustrates the same point:

int f(void)
{
puts("In f");
}

If the caller doesn't use the (nonexistent) result, there's no problem.

int main(void)
{
f();
return 0;
}

If the caller does attempt to use the result, as in:

int i = f();

then the behavior is undefined, by C99 6.9.1p12:

If the } that terminates a function is reached, and the value of
the function call is used by the caller, the behavior is
undefined.

and by C90 6.6.6.4:

If a return statement without an expression is executed, and the
value of the function call is used by the caller, the behavior
is undefined. Reaching the } that terminates a function is
equivalent to executing a return statement without an expression.

Which means, I think, that a function that sometimes returns a value and
sometimes doesn't is perfectly all right as long as the different
behaviours match the appropriate calls.

 

[Keith Thompson]

Which means, I think, that a function that sometimes returns a value and
sometimes doesn't is perfectly all right as long as the different
behaviours match the appropriate calls.

Yes. Well, it's "perfectly all right" in the sense that its behavior
is well defined. As a matter of programming style, either it should
always return a value or it should be two different functions.