Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > noreturn

Reply
Thread Tools

noreturn

 
 
Bill Cunningham
Guest
Posts: n/a
 
      08-16-2012
What does this new noreturn specifer do? Is it related to return?

Bill


 
Reply With Quote
 
 
 
 
Angel
Guest
Posts: n/a
 
      08-16-2012
On 2012-08-16, Bill Cunningham <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Bill Cunningham
Guest
Posts: n/a
 
      08-16-2012
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


 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      08-16-2012
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.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-16-2012
"Bill Cunningham" <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-16-2012
Keith Thompson <(E-Mail Removed)> writes:
> "Bill Cunningham" <(E-Mail Removed)> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      08-16-2012
On 2012-08-16, Bill Cunningham <(E-Mail Removed)> 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
 
Reply With Quote
 
Fred K
Guest
Posts: n/a
 
      08-17-2012
On Thursday, August 16, 2012 4:06:30 PM UTC-7, Angel wrote:
> On 2012-08-16, Bill Cunningham <(E-Mail Removed)> 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?
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-17-2012
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
 
Reply With Quote
 
Ralph Spitzner
Guest
Posts: n/a
 
      08-18-2012
Angel wrote:
> On 2012-08-16, Bill Cunningham <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments