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  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:   Wed, 26 Oct 2022 11:47:35 -0700
From:   Linus Torvalds <>
To:     Nick Desaulniers <>
Cc:     Kees Cook <>,,
Subject: Re: [PATCH] fortify: Do not cast to "unsigned char"

On Wed, Oct 26, 2022 at 11:26 AM Nick Desaulniers
<> wrote:
> If the intent of __p is to avoid repeated application of side effects
> from the evaluation of the macro parameter p, this could also be:

Not the only intent.

The code also does


which basically checks for "is this a compile-time constant string"
(yes, I realize that it only checks the first character, but it ends
up being the same thing).

That would fail horribly with __auto_type and people using "void *".

It is true that we could probably use __auto_type in a lot of other
places where we currently use

        __typeof__(ptr) _p_ = (ptr)

but our "typeof" pattern is

 (a) much more common because of historical reasons

 (b) much more generic because it often uses a different ptr type (ie
macros that have a value and a pointer, like "put_user()", the type
comes from the pointer, but the initializer comes from the value, so
"__auto_type" ends up being completely the wrong thing).

We do have a couple of "__auto_type" uses, but because it can't
replace our __typeof__ users in general anyway, I'm not convinced we
should strive to make it hugely more common (even if the __auto_type
model probably can replace a lot of them).


Powered by blists - more mailing lists