C99 Features

[Nathaniel McCallum]

On Wed, 2015-06-17 at 18:06 -0500, Nico Williams wrote:
> On Wed, Jun 17, 2015 at 02:32:15PM -0400, Nathaniel McCallum wrote:
> > On Wed, 2015-06-17 at 00:02 +0000, Danilo Almeida wrote:
> > > Nathaniel wrote:
> > > > I think VLAs buys a lot.
> > > 
> > > It seems that VLA could introduce new issues or invariants since 
> > > you 
> > > can no longer check for allocation failure.
> > 
> > You can't check for allocation failure on most operating systems' 
> > heap
> > allocation these days. Now, the failure in the heap vs stack cases 
> > is
> > somewhat different; and you have to be cautious to avoid some 
> > security
> > issues. But with careful use, there is a lot of benefit.
> 
> Heap allocation failures are rather different than alloca() or VLA
> allocation failures.  alloca(), for example, has undefined behavior 
> on
> failure for obvious reasons: sp + size might land in a mapped page 
> for a
> different mapping, going well past the stack's guard page.
> 
> In practice, if the stack grows down and the elements of the VLA are
> accessed from higher to lower (or the reverse if the stack grows up)
> then the guard page should still work, but this isn't defined 
> behavior.
> 
> Both are fine when the sizes are naturally limited to small sizes, 
> but
> this requires more review effort.  Alternatively one could have a 
> macro
> to guard against unsafe array sizes.  I'd rather VLAs and alloca() 
> were
> frowned upon (though not forbidden).

Most of this is greatly diminished by the various stack protection
techniques found in modern compilers. It is getting harder and harder
to even trigger these kinds of errors.

Nathaniel