On Fri, 25 May 2007, H. Peter Anvin wrote:
> Robert P. J. Day wrote:
> >
> >
> > f() __attribute__((noreturn)) ;
> >
> > you get:
> >
> > warning: data definition has no type or storage class
> >
> > but gcc doesn't complain if you declare it thusly:
> >
> > __attribute__((noreturn)) f() ;
> >
> > that strikes me as a flaw in gcc, no?
> >
>
> Doesn't matter. gcc accepts "void __attribute__((noreturn)) f();", and
> thus, one can define:
>
> #define __noreturn void __attribute__((noreturn))
>
> ... and declare functions as:
>
> __noreturn f();
>
> ... which is the syntactially sane way of doing it.
i've thought about this and, while i philosophically agree with you,
i'm not going down that road for a couple reasons.
first, there is the fact that there is already a macro definition for
__noreturn in include/linux/compiler-gcc.h:
#define __noreturn __attribute__((noreturn))
second, and more importantly, defining __noreturn as you suggest is
now mixing two fundamental pieces of information. "void" is a return
type, plain and simple. an attribute, OTOH, as i read it, is more of
a suggestion to the compiler to allow better checking of your code
and, based on future compilers, it may not even be meaningful.
all of the short forms for attributes defined in compiler-gcc.h are
exactly that -- short forms. by adding in a return type, you're
fundamentally changing the way that short cut can be used.
yes, i *know* that __noreturn makes the return type irrelevant. but
even the gcc manual doesn't try to take that extra step:
================================================================
A few standard library functions, such as abort and exit, cannot
return. GCC knows this automatically. Some programs define their own
functions that never return. You can declare them noreturn to tell the
compiler this fact. For example,
void fatal () __attribute__ ((noreturn));
void
fatal (...)
{
... /* Print error message. */ ...
exit (1);
}
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.
Do not assume that registers saved by the calling function are
restored before calling the noreturn function.
It does not make sense for a noreturn function to have a return type
other than void.
^^^^^ ^^^^ ^^^^
===============================================================
so I'm just going to stick with the pattern that's been used so far.
i realize it offends your sense of syntactic sensibility, but it's
just not worth treating that one attribute so differently from the
rest of them.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
