noreturn

Discussion in 'C Programming' started by Bill Cunningham, Aug 16, 2012.

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

    Bill
    Bill Cunningham, Aug 16, 2012
    #1
    1. Advertising

  2. Bill Cunningham

    Angel Guest

    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, Aug 16, 2012
    #2
    1. Advertising

  3. 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
    Bill Cunningham, Aug 16, 2012
    #3
  4. Bill Cunningham

    Nobody Guest

    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.
    Nobody, Aug 16, 2012
    #4
  5. "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/wg14/www/docs/n1570.pdf

    If not, just keep reading.

    --
    Keith Thompson (The_Other_Keith) <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, Aug 16, 2012
    #5
  6. Keith Thompson <> 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/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.

    --
    Keith Thompson (The_Other_Keith) <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, Aug 16, 2012
    #6
  7. Bill Cunningham

    Angel Guest

    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
    Angel, Aug 17, 2012
    #7
  8. Bill Cunningham

    Fred K Guest

    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?
    Fred K, Aug 17, 2012
    #8
  9. Bill Cunningham

    James Kuyper Guest

    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
    James Kuyper, Aug 17, 2012
    #9
  10. 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 :p


    --
    See why I hate Windows users?
    All pain, no gain.
    -Howard Chu
    Ralph Spitzner, Aug 18, 2012
    #10
  11. Bill Cunningham

    Les Cargill Guest

    Ralph Spitzner wrote:
    > 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_.
    >


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

    > (Read return address gets pulled off the stack)
    >
    > Not that my 0.02EUR are worth anything, these days :p
    >
    >

    --
    Les Cargill
    Les Cargill, Aug 18, 2012
    #11
  12. Ralph Spitzner <> writes:
    > 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 :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.)

    --
    Keith Thompson (The_Other_Keith) <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, Aug 18, 2012
    #12
  13. 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']


    --
    See why I hate Windows users?
    All pain, no gain.
    -Howard Chu
    Ralph Spitzner, Aug 19, 2012
    #13
  14. Ralph Spitzner <> writes:
    > 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?

    --
    Keith Thompson (The_Other_Keith) <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, Aug 19, 2012
    #14
  15. Bill Cunningham

    Angel Guest

    On 2012-08-19, Ralph Spitzner <> wrote:
    > 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.


    --
    "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, Aug 19, 2012
    #15
  16. 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)





    --
    See why I hate Windows users?
    All pain, no gain.
    -Howard Chu
    Ralph Spitzner, Aug 19, 2012
    #16
  17. Bill Cunningham

    Nobody Guest

    On Sat, 18 Aug 2012 20:41:30 +0200, Ralph Spitzner 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.


    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().
    Nobody, Aug 19, 2012
    #17
  18. Bill Cunningham

    Willem Guest

    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
    Willem, Aug 19, 2012
    #18
  19. On 19-Aug-12 12:02, Nobody wrote:
    > On Sat, 18 Aug 2012 20:41:30 +0200, Ralph Spitzner 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.

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

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Aug 19, 2012
    #19
  20. Bill Cunningham

    Les Cargill Guest

    Stephen Sprunk wrote:
    > On 19-Aug-12 12:02, Nobody wrote:
    >> On Sat, 18 Aug 2012 20:41:30 +0200, Ralph Spitzner 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.

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



    http://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html


    --
    Les Cargill
    Les Cargill, Aug 19, 2012
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page