«

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

Bill

On 2012-08-16, Bill Cunningham <> wrote:
> 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.


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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?

Bill

On Thu, 16 Aug 2012 19:35:52 +0000, Angel wrote:

> 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.

"Bill Cunningham" <> writes:
> What does this new noreturn specifer do? Is it related to return?

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/wg...docs/n1570.pdf

If not, just keep reading.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-> writes:
> "Bill Cunningham" <> writes:
>> What does this new noreturn specifer do? Is it related to return?
>
> 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/wg...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.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2012-08-16, Bill Cunningham <> 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 enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

On Thursday, August 16, 2012 4:06:30 PM UTC-7, Angel wrote:
> On 2012-08-16, Bill Cunningham <> 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?

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.
--
James Kuyper

Angel wrote:
> On 2012-08-16, Bill Cunningham <> wrote:
[....]
> 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


--
See why I hate Windows users?
All pain, no gain.
-Howard Chu