linux-kernel - Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 9 Sep 2021 14:14:17 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Jakub Jelinek <jakub@...hat.com>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Florian Weimer <fweimer@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        llvm@...ts.linux.dev, linux-toolchains@...r.kernel.org
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

On Tue, Sep 7, 2021 at 11:54 PM Segher Boessenkool
<segher@...nel.crashing.org> wrote:
>
> On Mon, Sep 06, 2021 at 11:52:18PM +0200, Jakub Jelinek wrote:
> > On Mon, Sep 06, 2021 at 02:08:58PM -0700, Linus Torvalds wrote:
> > There is a stddef.h include too and that's it
> > (I must say I don't see the reason for that include though).
>
> Yeah me neither.  Maybe the header used NULL before?
>
> > Other compiler provided headers (not talking about C++ now) also have no
> > or very limited includes, including stddef.h, stdarg.h, stdatomic.h, etc.
> > The only exceptions are tgmath.h which isn't usable without libc
> > math.h/complex.h,
>
> <tgmath.h> is only for hosted environments.  That requires a C library
> for GCC (we do not implement this stuff ourselves).  The compiler and
> the C library have to work together to get this done, and the relation
> between GCC and Glibc has been a bit too tight for this, it is true.
>
> But a kernel build is not in a hosted environment.
>
> > in some cases stdint.h and limits.h which are in some
> > configurations provided both by the C library and the compiler and include
> > each other in that case (but e.g. stdint.h has an alternate version that
> > only uses compiler provided builtin macros) and openacc.h.
>
> On what targets is <stdint.h> still problematic?  And <limits.h>?


Since commit 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf
all architectures in the kernel space use the same fixed-width
types, which are defined by
include/uapi/asm-generic/int-ll64.h

So, u32 is always 'unsigned int',
and u64 is always 'unsigned long long'.

It is convenient for printk() in common code
because we can always use the 'll' prefix for u64.


  u32 foo = 1;
  u64 bar = 1;

  printk("foo = %u\n", foo);
  printk("bar = %llu\n, bar);



If we use compiler-provided <stdint.h>,
it is not convenient for printk() because
uint64_t is 'unsigned long' on some compilers
and 'unsigned long long' on others.

<intypes.h> provides macros such as PRIx64

    uint32_t foo = 1;
    uint64_t bar = 1;

    printk("foo = %" PRIu32 "\n", foo);
    printk("bar = %" PRIu64 "\n", bar);


This works, but ends up with ugly code,
which I want to avoid.












--
Best Regards
Masahiro Yamada