lkml.org 
[lkml]   [2019]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] scheduler fixes
    On Sun, Nov 17, 2019 at 2:20 AM Valentin Schneider
    <valentin.schneider@arm.com> wrote:
    >
    > AFAIUI the requirement for the enum type is that it has to be an int type that
    > covers all its values, so I could see some funky optimization (e.g. check the
    > returned value is < 512 but it's assumed the type for the enum is 8 bits so
    > this becomes always true). Then again we don't have any explicit check on
    > those returned values, plus they fit in 11 bits, so as you say it's
    > mostly likely inconsequential (and I didn't see any compile diff).

    Gcc can - and does - narrow enums to smaller integer types with the
    '-fshort-enums' flag.

    However, in practice nobody uses that, and it can cause interop
    problems. So I think for us, enums are always at least 'int' (they can
    be bigger).

    That said, mixing enums and values that are bigger than the enumerated
    ones is just a bad idea

    It will, for example, cause us to miss compiler warnings (eg switch
    statements with an enum will warn if you don't handle all cases, but
    the 'all cases' is based on the actual enum range, not on the
    _possible_ invalid values).

    Linus

    \
     
     \ /
      Last update: 2019-11-17 17:30    [W:2.645 / U:1.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site