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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 3 Feb 2022 00:01:14 +0100
From:   Miguel Ojeda <>
To:     David Laight <>
Cc:     Kees Cook <>,
        Jonathan Corbet <>,
        Linus Torvalds <>,
        Martin Uecker <>,
        Ingo Molnar <>,
        Rikard Falkeborn <>,
        Arnd Bergmann <>,
        "" <>,
        Tetsuo Handa <>,
        Andrew Morton <>,
        Andy Shevchenko <>,
        Nick Desaulniers <>,
        "Gustavo A. R. Silva" <>,
        "" <>,
        "" <>
Subject: Re: [PATCH] linux/const.h: Explain how __is_constexpr() works

On Wed, Feb 2, 2022 at 11:20 PM David Laight <> wrote:
> The type of the result depends on the type of the 2nd and 3rd arguments.
> Not on the value of the first one.

I am not talking about the first operand. The behavior of the
conditional operator has a few cases. Since you mentioned promotions,
it looked like you were thinking about what happens for the arithmetic
types case, i.e.

"""If both the second and third operands have arithmetic type, the
result type that would be determined by the usual arithmetic
conversions, were they applied to those two operands, is the type of
the result."""

which could lead to thinking that the expressions need to have the
same type as you mentioned, but that is not true, and the arithmetic
types case is not used in the macro either. The cases used are the
null pointer constant vs. pointer and the pointer to void vs. pointer
to object type.

> It has nothing to with the condition, the compiler is trying to 'sort out'
> a suitable return type.
> I suspect the mismatched pointer types might even be a gcc extension.

That is why I said it does not fit the constraints of the operator.
The standard does not describe what happens in such a case.


Powered by blists - more mailing lists