On Thu, Mar 8, 2018 at 5:35 PM, Linus Torvalds
wrote:
> I don't want to weaken the type enforcement, and I _thought_ you had
> done that __builtin_types_compatible_p() to keep it in place.
I thought so too (that originally came from Josh), but on removal, I
was surprised that the checking was ret
On Thu, Mar 8, 2018 at 4:45 PM, Kees Cook wrote:
>
> Rasmus mentioned this too. What I said there was that I was shy to
> make that change, since we already can't mix that kind of thing with
> the existing min()/max() implementation. The existing min()/max() is
> already extremely strict, so there
On Thu, Mar 8, 2018 at 3:48 PM, Linus Torvalds
wrote:
> On Thu, Mar 8, 2018 at 1:40 PM, Kees Cook wrote:
>> +#define __min(t1, t2, x, y)\
>> + __builtin_choose_expr(__builtin_constant_p(x) &&\
>> + __bui
On Thu, Mar 8, 2018 at 1:40 PM, Kees Cook wrote:
> +#define __min(t1, t2, x, y)\
> + __builtin_choose_expr(__builtin_constant_p(x) &&\
> + __builtin_constant_p(y) &&\
> +
On Thu, Mar 8, 2018 at 2:18 PM, Andrew Morton wrote:
> On Thu, 8 Mar 2018 13:40:45 -0800 Kees Cook wrote:
>
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
>> thinks this is a dynamic calculation d
On Thu, 8 Mar 2018 13:40:45 -0800 Kees Cook wrote:
> When max() is used in stack array size calculations from literal values
> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> thinks this is a dynamic calculation due to the single-eval logic, which
> is not needed in the li
On Thu, 2018-03-08 at 13:40 -0800, Kees Cook wrote:
>
> +#define __min(t1, t2, x, y) \
> + __builtin_choose_expr(__builtin_constant_p(x) &&\
> + __builtin_constant_p(y) &&\
> +
When max() is used in stack array size calculations from literal values
(e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
thinks this is a dynamic calculation due to the single-eval logic, which
is not needed in the literal case. This change removes several accidental
stack VLAs