Paolo Bonzini <pbonz...@redhat.com> writes: > On 31/01/2017 22:49, Markus Armbruster wrote: >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >>> On 31/01/2017 12:40, Markus Armbruster wrote: >>>>> >>>>> #define QEMU_NORETURN __attribute__ ((__noreturn__)) >>>>> >>>>> -#if QEMU_GNUC_PREREQ(3, 4) >>>>> #define QEMU_WARN_UNUSED_RESULT __attribute__((warn_unused_result)) >>>>> -#else >>>>> -#define QEMU_WARN_UNUSED_RESULT >>>>> -#endif >>>> Should we inline this macro? >>>> >>>>> >>>>> -#if QEMU_GNUC_PREREQ(4, 0) >>>>> #define QEMU_SENTINEL __attribute__((sentinel)) >>>>> -#else >>>>> -#define QEMU_SENTINEL >>>>> -#endif >>>> Likewise. >>> >>> Why, since we don't do that for QEMU_NORETURN, QEMU_PACKED, etc.? >> >> Because we do it for aligned, always_inline, constructor, format, mode, >> noinline, and in places even noreturn and packed: >> >> $ git-grep __attribute__ | sed '/define/d;s/.*__attribute__ >> *((\([A-Za-z0-9_]*\).*/\1/' | sort -u >> > > Uh oh. :) You have to remove uses in firmware and in imported code > (which covers mode, format and noreturn), but there's certainly room for > some BiteSizedTasks. > > For sure noinline should be wrapped by a macro so that you also include > noclone (usually you want to thwart some compiler optimization so both > are needed). > > That leaves aligned, always_inline and constructor. always_inline has > three users, constructors has many, aligned has many and there's > QEMU_ALIGNED too. The smallest work would be to convert these three to > QEMU_* rather than convert QEMU_* to __attribute__.
I prefer "direct" expression to hiding behind macros, unless there's a reason for macros. A common reason is portability. Occasionally abstraction, say when the direct expression doesn't really convey what you're trying to do, or it's is overly verbose. Anyway, I'm not particular on how we use attributes. Since you seem to have more specific ideas, could you file suitable BiteSizedTasks?
