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  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 8 Jun 2021 03:02:16 +0530
From:   Dwaipayan Ray <dwaipayanray1@...il.com>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     Joe Perches <joe@...ches.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v2] docs: checkpatch: Document and segregate more
 checkpatch message types

On Mon, Jun 7, 2021 at 7:17 PM Dwaipayan Ray <dwaipayanray1@...il.com> wrote:
>
> > > +  **CONSTANT_CONVERSION**
> > > +    Use of __constant_<foo> form is discouraged for the following functions::
> > > +
> > > +      __constant_cpu_to_be[x]
> > > +      __constant_cpu_to_le[x]
> > > +      __constant_be[x]_to_cpu
> > > +      __constant_le[x]_to_cpu
> > > +      __constant_htons
> > > +      __constant_ntohs
> > > +
> > > +    Using any of these outside of include/uapi/ isn't preferred as using the
> >
> > write out: s/isn't/is not/
> >
> > ...or even stylistically much better is to just write the
> > recommendation positively and clear:
> >
> > Use the corresponding function without __constant_ prefix, e.g., htons
> > instead of __constant_htons, for any use in files, except
> > include/uapi/.
> >
> > Are there other __constant_ functions in the code base beyond all the
> > ones you listed? Then, we should explain why only those above and why
> > not the others. Otherwise, we can keep the list above quite brief, and
> > just say all __constant_ functions can be replaced by their
> > counterparts without __constant_ prefix.
> >

So, as Lukas said, I came up with this updated explanation for
constant conversion:

  **CONSTANT_CONVERSION**
    Use of __constant_<foo> form is discouraged for the following functions::

      __constant_cpu_to_be[x]
      __constant_cpu_to_le[x]
      __constant_be[x]_to_cpu
      __constant_le[x]_to_cpu
      __constant_htons
      __constant_ntohs

    Using any of these outside of include/uapi/ is not preferred as using the
    function without __constant_ is identical when the argument is a
    constant.

    In big endian systems, the macros like __constant_cpu_to_be32(x) and
    cpu_to_be32(x) expand to the same expression::

      #define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x))
      #define __cpu_to_be32(x)          ((__force __be32)(__u32)(x))

    In little endian systems, the macros __constant_cpu_to_be32(x) and
    cpu_to_be32(x) expand to __constant_swab32 and __swab32.  __swab32
    has a __builtin_constant_p check::

      #define __swab32(x) \
        (__builtin_constant_p((__u32)(x)) ? \
        ___constant_swab32(x) : \
        __fswab32(x))

    So ultimately they have a special case for constants.
    Similar is the case with all of the macros in the list.  Thus
    using the __constant_... forms are unnecessarily verbose and
    not preferred outside of include/uapi.

    See: https://lore.kernel.org/lkml/1400106425.12666.6.camel@joe-AO725/

Can Lukas or Joe confirm this or have any comments on it. I can send
an updated patch then.

Thanks,
Dwaipayan.

Powered by blists - more mailing lists