noreturn

A

Angel

What does this new noreturn specifer do? Is it related to return?

In a way yes. It tells the compiler that this function is not supposed
to return at all. This allows the compiler to make certain optimizations
which it couldn't make if the function should be expected to return.

In the standard library, the functions exit() and abort() are examples
of functions that never return, since calling either ends the program.

A function that is marked as noreturn should of course never contain a
return statement, nor should it be allowed to "fall off" at the end of
the function definition.
 
B

Bill Cunningham

Angel said:
In a way yes. It tells the compiler that this function is not
supposed to return at all. This allows the compiler to make certain
optimizations which it couldn't make if the function should be
expected to return.

In the standard library, the functions exit() and abort() are examples
of functions that never return, since calling either ends the program.

A function that is marked as noreturn should of course never contain a
return statement, nor should it be allowed to "fall off" at the end of
the function definition.

So should void always be a function's type with this? Do we just
basically have a new specifier here?

Bill
 
N

Nobody

In the standard library, the functions exit() and abort() are examples of
functions that never return, since calling either ends the program.

Not quite. 7.20.4.1p2:

The abort function causes abnormal program termination to
occur, unless the signal SIGABRT is being caught and the
signal handler does not return.

IOW, abort() is guaranteed not to return, but it isn't guaranteed to
terminate the program. A signal handler which calls longjmp() may prevent
termination.

The Linux/glibc implementation unblocks SIGABRT, raises it, restores
the default disposition, then raises it again.
 
K

Keith Thompson

Keith Thompson said:
Did you read something that mentions the "noreturn" specifier without
explaining what it means?

If so, the latest C11 draft is at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

If not, just keep reading.

One possible source of confusion: the standard says:

A function declared with a _Noreturn function specifier shall not
return to its caller.

Since the "shall" is not in a constraint, that means that if such a
function *does* return to its caller, the behavior is undefined.

No-return functions are typically declared as returning void, but that's
not required. It could make sense to have a non-void no-return function
if it's one of several functions that need to have the same type (say,
if they're called via a function pointer). I expect that would be an
unusual situation, though.
 
A

Angel

So should void always be a function's type with this? Do we just
basically have a new specifier here?

I couldn't find anything that requires the return type to be void, but
since the function is not supposed to return at all, a return type of
void seems the most logical choice to me.
 
F

Fred K

On 2012-08-16, Bill Cunningham <[email protected]> wrote: > Angel wrote: > >> In a way yes. It tells the compiler that this function is not >> supposed to return at all. This allows the compiler to make certain >> optimizations which it couldn't make if the function should be >> expected to return. >> >> In the standard library, the functions exit() and abort() are examples >> of functions that never return, since calling either ends the program. >> >> A function that is marked as noreturn should of course never contain a >> return statement, nor should it be allowed to "fall off" at the end of >> the function definition. > > So should void always be a function's type with this? Do we just > basically have a new specifier here? I couldn't find anything that requires the return type to be void, but since the function is not supposed to return at all, a return type of void seems the most logical choice to me. -- "C provides a programmer with more than enoughrope to hang himself. C++ provides a firing squad, blindfold and last cigarette." - seen in comp.lang.c

Any function that calls a noreturn function, where the call is not inside
a conditional block, also never return.
Most X/Motif programs never return from main() - they call XtAppMainLoop(),which never returns. So should maiin() in this case be apscified as noreturn?

IF so, should it still have a return at the end? If there is no return statement at the end of a non-void noreturn function, will the compiler refrainfrom complaining about the missing return?
 
J

James Kuyper

On 08/17/2012 10:27 AM, Fred K wrote:
....
Any function that calls a noreturn function, where the call is not inside
a conditional block, also never return.
Most X/Motif programs never return from main() - they call XtAppMainLoop(), which never returns. So should maiin() in this case be apscified as noreturn?

If it did, the behavior would be undefined, unless it was a free
standing environment: 6.7.4p4: "In a hosted environment, no function
specifier(s) shall appear in a declaration of main."
IF so, should it still have a return at the end? If there is no return statement at the end of a non-void noreturn function, will the compiler refrain from complaining about the missing return?

Such code doesn't violate any constraints, so it's up to the
implementation whether or not it wants to complain about such code.

6.7.4p8: "A function declared with a _Noreturn function specifier shall
not return to its caller."

The behavior would be undefined, but only if the return statement were
actually executed. An unreachable return statement would not be a
problem (but would likely generate warning messages.
 
R

Ralph Spitzner

Angel said:
In the standard library, the functions exit() and abort() are examples
of functions that never return, since calling either ends the program.

Hmm, as far as I see it, the only function which does actually
_never_ return to anything is the main loop of the OS.
All others are subject to garbage collection and heap cleanup.
Therefore they have to return to _something_.

(Read return address gets pulled off the stack)

Not that my 0.02EUR are worth anything, these days :p
 
L

Les Cargill

Ralph said:
Hmm, as far as I see it, the only function which does actually
_never_ return to anything is the main loop of the OS.
All others are subject to garbage collection and heap cleanup.
Therefore they have to return to _something_.

Any "main" for a thread will be no-return, and will
be an "infinite loop".
 
K

Keith Thompson

Ralph Spitzner said:
Hmm, as far as I see it, the only function which does actually
_never_ return to anything is the main loop of the OS.
All others are subject to garbage collection and heap cleanup.
Therefore they have to return to _something_.

(Read return address gets pulled off the stack)

Not that my 0.02EUR are worth anything, these days :p

"Return" does not just mean "terminate". The `noreturn` or
`_Noreturn` function specifier means that the function never executes
a `return` statement and never reaches its closing `}`. It's about the
C `return` statement, not about pulling the return address off the stack
(even if there is a stack).

For example, this function:

_Noreturn void func(void) {
while (1) {
do_something();
sleep(1);
}
}

will terminate when the program is terminated, but it never returns to
its caller, so the `_Noreturn` is appropriate.

(Note: `...` is the Markdown syntax for code samples; see
<http://en.wikipedia.org/wiki/Markdown>. I'm going to start using it
here.)
 
R

Ralph Spitzner

Keith Thompson wrote:
[...]
For example, this function:

_Noreturn void func(void) {
while (1) {
do_something();
sleep(1);
}
}

will terminate when the program is terminated, but it never returns to
its caller, so the `_Noreturn` is appropriate.

Yes, but that do_something() might actually do something :)
like allocating memory an possibly forgetting to free() it.
So something has to watch over it, which will notice the
program has 'returned/terminated'.

[That's just my perception of a 'return']
 
K

Keith Thompson

Ralph Spitzner said:
Keith Thompson wrote:
[...]
For example, this function:

_Noreturn void func(void) {
while (1) {
do_something();
sleep(1);
}
}

will terminate when the program is terminated, but it never returns to
its caller, so the `_Noreturn` is appropriate.

Yes, but that do_something() might actually do something :)
like allocating memory an possibly forgetting to free() it.

Yes, that would be a memory leak.
So something has to watch over it, which will notice the
program has 'returned/terminated'.

There's no requirement in the language for a mechanism to detect memory
leaks.
[That's just my perception of a 'return']

The meaning of 'return' isn't a matter of perception.

Are you arguing that the use of `_Noreturn` in my example is incorrect,
or that it should mean something other than what the standard says it
means?
 
A

Angel

Keith Thompson wrote:
[...]
For example, this function:

_Noreturn void func(void) {
while (1) {
do_something();
sleep(1);
}
}

will terminate when the program is terminated, but it never returns to
its caller, so the `_Noreturn` is appropriate.

Yes, but that do_something() might actually do something :)
like allocating memory an possibly forgetting to free() it.
So something has to watch over it, which will notice the
program has 'returned/terminated'.

"noreturn" merely specifies that the function never returns to its
caller. It says nothing about whether the program keeps running after
that. The program could terminate immediately, like the exit() function
for example. It could be running indefinitely, for example the main
execution loop of a game. "noreturn" merely specifies that this function
will never execute a return statement or "fall off" at the end of its
definition.
[That's just my perception of a 'return']

In C, the meaning of "return" is well defined and not subject to
personal perception.
 
R

Ralph Spitzner

Keith Thompson wrote:
[...]
The meaning of 'return' isn't a matter of perception.

Are you arguing that the use of `_Noreturn` in my example is incorrect,
or that it should mean something other than what the standard says it
means?
No, not arguing about the _Noreturn statement itself (which might be
making things easier for the optimizer), but rather about that a
function must end somehow, be it by a kill -9.
Unless you're running on bare metal something will catch that
termination and clean up,therefore having noticed a 'return' :p

Maybe that noreturn statement is just a little bit too abstract,
or the term is just strange to me.

The compiler could just grok it by seeing something like
for(;;)
or
while(1)
 
N

Nobody

Hmm, as far as I see it, the only function which does actually
_never_ return to anything is the main loop of the OS.

The issue is whether it actually *returns* to its caller. Other examples
of functions which don't return are longjmp() and execve(). Grey areas
include setjmp() and swapcontext().
 
W

Willem

Ralph Spitzner wrote:
) Keith Thompson wrote:
) [...]
)> The meaning of 'return' isn't a matter of perception.
)>
)> Are you arguing that the use of `_Noreturn` in my example is incorrect,
)> or that it should mean something other than what the standard says it
)> means?
)>
) No, not arguing about the _Noreturn statement itself (which might be
) making things easier for the optimizer), but rather about that a
) function must end somehow, be it by a kill -9.
) Unless you're running on bare metal something will catch that
) termination and clean up,therefore having noticed a 'return' :p

Again: that's not what "return" means! So stop playing Humpty-Dumpty.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
S

Stephen Sprunk

The issue is whether it actually *returns* to its caller. Other examples
of functions which don't return are longjmp() and execve(). Grey areas
include setjmp()

AIUI, setjmp() always returns at least once--and sometimes more than once.
and swapcontext().

I'm not familiar with that one.

S
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top