Andrew Haley schrieb:
Daniel Lohmann writes:
> Angus schrieb:
> >
> > BTW, in my opinion it is dangerous. Usually one can rely on
> > compile or link errors to catch mismatched function
> > characteristics, but with attributes there is no such
> > checking. So even if you aren't doing something *really*
> > dangerous, like working with virtual methods, you might do what I
> > did, and you'll never know about it until you notice you've
> > mismatched your attributes. So if you ask me, attributes like
> > this one should be used sparingly, and with much caution.
>
> I would consider this as a significant defect of gcc's attribute handling.
> Attributes that change a function to a non-standard calling convention
> effectively modify the interface of the function, which should be encoded
> into the (mangled) symbol name. Thereby incompatible prototypes on on the
> caller and callee side could be detected at link-time.
But attributes such as fastcall are used in C programs, and C doesn't
do mangling.
But in this cases it should! As soon as we use the fastcall (or interrupt
or interrupt_handler or ...) attribute, we already have left the safe haven
of the C ABI for an inherently incompatible compiler-specific extensions.
Pretending nevertheless compatibility to the standard ABI at link time is
just insane.
I don't know that many people combine C++ and weirdo
attributes like fastcall.
You would be surprised. C++ is facing an immense popularity gain in the
embedded systems community. And these people (I am one of them...) often
need a much finer control over code generation.
This may also explain the increasing requests for #pragma support in gcc. I
know, the gcc guys favor attributes - which are a great thing, indeed.
However, IMHO attributes and pragmas, despite the fact that they *can* be
used to achieve the same effects, are completely orthogonal concepts.
Actually, we need them both. But I suppose this issue has already been
discussed too many times.
Otherwise it's not such a bad idea, but it
is an ABI change: such changes, being non-backwards compatible, are
usually unpopular.
For good reasons. But maybe in gcc 5...
Daniel
