lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 9 Mar 2020 22:27:59 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <davem@...emloft.net>, <saeedm@...lanox.com>, <leon@...nel.org>,
        <michael.chan@...adcom.com>, <vishal@...lsio.com>,
        <jeffrey.t.kirsher@...el.com>, <idosch@...lanox.com>,
        <aelior@...vell.com>, <peppe.cavallaro@...com>,
        <alexandre.torgue@...com>, <jhs@...atatu.com>,
        <xiyou.wangcong@...il.com>, <pablo@...filter.org>,
        <mlxsw@...lanox.com>
Subject: Re: [patch net-next v4 01/10] flow_offload: Introduce offload of HW
 stats type

On 09/03/2020 21:36, Jakub Kicinski wrote:
> ...but using the type for fields which are very likely to contain
> values from outside of the enumeration seems confusing, IMHO.
It's the only way I can see to (a) ensure that the field is the correct
 size and (b) document the connection between the field and the type.

Now, I'm not saying that using the enums actually buys any real type-
 safety — the C standard enums are far too weak for that, being
 basically ints with hair — but the mythical Sufficiently Smart
 Compiler might be able to get some mileage out of it to issue better
 diagnostics.

> Driver author can understandably try to simply handle all the values 
> in a switch statement and be unpleasantly surprised.
In my experience, unenumerated enum values of this kind are fully
 idiomatic C; and a driver author looking at the header file to see
 what enumeration constants are defined will necessarily see all the
 calls to BIT() and the bitwise-or construction of _ANY.
I'm not sure I believe a naïve switch() implementation is an
 "understandable" error.

How about if we also rename the field "hw_stats_types", or squeeze
 the word "mask" in there somewhere?

-ed

Powered by blists - more mailing lists