[19211] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Thu Jun 18 00:24:31 2015
Message-ID: <1434601444.15953.9.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Danilo Almeida <dalmeida@mit.edu>,
"nico@cryptonector.com"
<nico@cryptonector.com>
Date: Thu, 18 Jun 2015 00:24:04 -0400
In-Reply-To: <33E2E06D4C33464A97D0F4884B25430658AB25C8@OC11EXPO25.exchange.mit.edu>
Mime-Version: 1.0
Cc: "'krbdev@mit.edu'" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, 2015-06-18 at 01:13 +0000, Danilo Almeida wrote:
> <quote from="Nico">
> 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).
> </quote>
>
> I am not sure how such a macro would work.
>
> Otherwise, I mostly agree with Nico, except that I am not comfortable
> with the "though not forbidden" part. Nathaniel, do you have any
> performance numbers would help the case for the extra effort (and
> potential risk)?
Well, take common inner-function heap allocations and turn them into
stack allocations. That is a significant performance gain.
VLAs make perfect sense for operations like fx_cf2 where you need to
mix two keys together using intermediary buffers. If you validate that
the input keys are valid types then you know that the buffer for that
type will be a sensible size to put on the stack. This eliminates two
unnecessary heap allocations.
Nathaniel
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
