what's the point of a return type with "__attribute__((noreturn))"?

what's the point of a return type with "__attribute__((noreturn))"?

[Robert P. J. Day]

  at the moment, we're having an animated discussion over at the linux
kernel mailing list regarding proper usage of attributes, so i'd like
to ask a few questions about how people tend to use them.  as
examples, let's say i wanted to tag a function as deprecated.

  first, i'm assuming that the function declaration (if there is one)
can be written as any one of:

__attribute__((deprecated)) int fubar(void);
int __attribute__((deprecated)) fubar(void);
int fubar(void) __attribute__((deprecated));

  that is, the attribute placement in the declaration is flexible,
even though it appears that that last form seems to be the most
popular, is that right?

  next, once i set an attribute on a function *declaration*, there's
no need to also set it on the subsequent function *definition*.  i
mean, i *could* but that would be redundant, correct?  however, in the
case where there is *only* a function definition, i could write that
definition in one of two ways:

__attribute__((deprecated)) int fubar(void) { ... }
int __attribute__((deprecated)) fubar(void) { ... }

  and, again, that second form seems to be more popular.  so far, so
good?  (just to clarify this in my mind, most of the declarations i've
seen have the attribute at the end, while most definitions put the
attribute between the return type and the routine name.)

  the big issue, though, involves "__attribute__((noreturn))".
the gcc manual on this page:

http://www.delorie.com/gnu/docs/gcc/gcc_55.html

shows the following snippet of code:

...
void fatal () __attribute__ ((noreturn));

void
fatal (...)
{
  ... /* Print error message. */ ...
  exit (1);
}
...

to keep a long question short, even though a "noreturn" routine
doesn't return, is it still traditional to declare it with a return
type of "void"?  thanks.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

RE: what's the point of a return type with "__attribute__((noreturn))"?

[John (Eljay) Love-Jensen]

Hi Robert,

The reason that qualifiers, such as __attribute__, are often seen on the right side of the symbol that the attribute is being applied to is because the rule goes:

a qualifier binds to the thing to its immediate left

Hence:

int const i = 0;

Or:

class Foo
{
public:
  virtual Bar() const;
};

The exception to the rule is:

unless the qualifier is the very first thing (and as such, there is no thing to its immediate left), then it binds to the thing to its immediate right

Hence:

const int i = 0; // The exception to the general rule.

In my experience, for "simple" declaration and definitions, the qualifier is quite often done first.  That's not the way I do it, but it is the way that 90%+ (maybe 99%+) of C++ developers do it.

The exception tends to not be used when a) it's more confusing to use it, or b) it cannot be used.

char const* const* * const* * ptr;

The first 'const' could, optionally, be put first before the 'char'.

But something like this reads better as is, when read right-to-left:
a pointer to a pointer to a const pointer to a pointer to a const pointer to a const char.

(I've never actually needed some monstrosity like that.  Just for over-the-top exemplary purposes.  At least I didn't use a function pointer.  Hmmm, ever notice that you can't tell which of those pointers are pointers to thingies and which are pointers to arrays of thingies?  Oh well.  Doesn't matter for this example, although I was keeping that in mind when I wrote it.)

The point of a __attribute__((noreturn)) function from <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>...
- - - - - - - - - - - - - - - - -
The noreturn keyword tells the compiler to assume that fatal cannot return. It can then optimize without regard to what would happen if fatal ever did return. This makes slightly better code. More importantly, it helps avoid spurious warnings of uninitialized variables.
- - - - - - - - - - - - - - - - -

HTH,
--Eljay