Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Mar 2018 17:44:52 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <>, Florian Weimer
CC: Kees Cook <>, Andrew Morton
	<>, Josh Poimboeuf <>, "Rasmus
 Villemoes" <>, Randy Dunlap <>,
	Miguel Ojeda <>, Ingo Molnar
	<>, Ian Abbott <>, linux-input
	<>, linux-btrfs <>,
	Network Development <>, Linux Kernel Mailing List
	<>, Kernel Hardening
Subject: RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

From: Linus Torvalds
> Sent: 16 March 2018 17:29
> On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer <> wrote:
> >
> > If you want to catch stack frames which have unbounded size,
> > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant
> > adjusted as needed) might be the better approach.
> No, we want to catch *variable* stack sizes.
> Does "-Werror=vla-larger-than=0" perhaps work for that? No, because
> the stupid compiler says that is "meaningless".
> And no, using "-Werror=vla-larger-than=1" doesn't work either, because
> the moronic compiler continues to think that "vla" is about the
> _type_, not the code:
>    t.c: In function ‘test’:
>    t.c:6:6: error: argument to variable-length array is too large
> [-Werror=vla-larger-than=]
>      int array[(1,100)];
> Gcc people are crazy.
> Is there really no way to just say "shut up about the stupid _syntax_
> issue that is entirely irrelevant, and give us the _code_ issue".

I looked at the generated code for one of the constant sized VLA that
the compiler barfed at.
It seemed to subtract constants from %sp separately for the VLA.
So it looks like the compiler treats them as VLA even though it
knows the size.
That is probably missing optimisation.


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.