[lkml]   [2012]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/4] compiler.h: introduce unused_expression() macro
    On Wed, 25 Apr 2012 15:26:23 +0400
    Konstantin Khlebnikov <> wrote:

    > Sometimes we want to check some expressions correctness in compile-time without
    > generating extra code. "(void)(e)" does not work if expression has side-effects.
    > This patch introduces macro unused_expression() which helps in this situation.
    > Cast to "long" required because sizeof does not work for bit-fields.
    > Signed-off-by: Konstantin Khlebnikov <>
    > ---
    > include/linux/compiler.h | 2 ++
    > 1 file changed, 2 insertions(+)
    > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
    > index 923d093..46fbda3 100644
    > --- a/include/linux/compiler.h
    > +++ b/include/linux/compiler.h
    > @@ -310,4 +310,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
    > */
    > #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
    > +#define unused_expression(e) ((void)(sizeof((__force long)(e))))
    > +

    hm, maybe.

    Thing is, if anyone ever has an expression-with-side-effects within
    conditionally-compiled code then they probably have a bug, don't they?
    I mean, as an extreme example


    is a nice little hand-grenade. Your patch will cause that (bad) code
    to newly fail at runtime, but our coverage testing is so awful that it
    would take a long time for the bug to be discovered.

    It would be nice if we could cause the build to warn or outright fail
    if the unused_expression() argument would have caused any code
    generation. But I can't suggest how to do that.

    Your changelogs assert that gcc is emitting code for these expressions,
    but details are not presented. Please give examples - where is this
    code generation coming from, what is causing it?

    Bottom line: are these patches a workaround for gcc inadequacies, or
    are they a bandaid covering up poor kernel code?

     \ /
      Last update: 2012-04-27 06:21    [W:0.022 / U:74.980 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site