lkml.org 
[lkml]   [2016]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] fs: dcache: Use bool return value instead of int
    Hello all:

    Is this patch OK? shall I send the other patch based on this one? (the
    other patch is v3 trivial patch for include/linux/dcache.h).

    And sorry for replying late: the last week, I was not in Beijing, had to
    be busy for analyzing a Linux kernel usb related issue for my company's
    customer in Guangzhou (but at last, I guess, it is not kernel issue).


    Thanks.

    On 1/14/16 23:39, Chen Gang wrote:
    >
    > On 1/14/16 06:54, Al Viro wrote:
    >> On Thu, Jan 14, 2016 at 06:39:53AM +0800, Chen Gang wrote:
    >>
    >>>> As for the inlines... frankly, if gcc generates a different code from having
    >>>> replaced int with bool in those, it's time to do something very nasty to
    >>>> gcc developers.
    >>>>
    >>>
    >>> Could you provide the related proof?
    >>
    >> static inline _Bool f(.....)
    >> {
    >> return <int expression>;
    >> }
    >>
    >> ...
    >> if (f(.....))
    >>
    >
    > For me, your case above isn't suitable for using bool. Please check this
    > patch, there is no any cases like you said above.
    >
    > - For d_unhashed() which return hlist_bl_unhashed(), it seems like your
    > case, but in fact hlist_bl_unhashed() also need return bool (which I
    > shall send another patch for, next).
    >
    > - And all the other changes of this patch are all for real, pure bool
    > functions.
    >
    > Thanks.
    >
    >> should generate the code identical to
    >> if ((_Bool)<int expression>)
    >> which, in turn, should generate the code identical to
    >> if (<int expression> != 0)
    >> and
    >> if (<int expression>)
    >>
    >> Neither explicit nor implicit conversion to _Bool (the former by the explicit
    >> cast, the latter - by declaring f() to return _Bool) matters at all when the
    >> damn thing is inlined in a condition context. Conversion to _Bool is
    >> equivalent to comparison with 0, and so is the use in condition of if() and
    >> friends.
    >>
    >> For something not inlined you might get different code generated due to a
    >> difference in calling sequences of _Bool(...) and int(...); for inlined
    >> case having one of those variants produce a better code means that compiler
    >> has managed to miss some trivial optimization in all other variants.
    >>
    >> And I'm yet to see any proof that gcc *does* fuck up in that fashion. It
    >> might - dumb bugs happen to everyone, but I would not assume that they'd
    >> managed to do something that bogys without experimental evidence.
    >>
    >
    > For your cases, what you said sounds OK to me (although I am not quite
    > sure what you said above whether precise or not).
    >
    > Thanks.
    >

    --
    Chen Gang (陈刚)

    Open, share, and attitude like air, water, and life which God blessed

    \
     
     \ /
      Last update: 2016-01-24 23:01    [W:3.055 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site