[19228] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Roland Mainz)
Thu Jul 9 12:06:49 2015
Date: Thu, 9 Jul 2015 12:05:06 -0400 (EDT)
From: Roland Mainz <rmainz@redhat.com>
To: Danilo Almeida <dalmeida@mit.edu>
Message-ID: <978053107.42937113.1436457906604.JavaMail.zimbra@redhat.com>
In-Reply-To: <33E2E06D4C33464A97D0F4884B25430658AB25C8@OC11EXPO25.exchange.mit.edu>
MIME-Version: 1.0
Cc: nico@cryptonector.com, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
----- Original Message -----
> From: "Danilo Almeida" <dalmeida@mit.edu>
> To: nico@cryptonector.com, npmccallum@redhat.com
> Cc: "krbdev@mit.edu" <krbdev@mit.edu>
> Sent: Thursday, June 18, 2015 3:13:40 AM
> Subject: RE: C99 Features
>
> <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)?
It's not all about short-term per-function/module/etc. performance - it's also about major cases of heap fragmentation caused by temporary-buffer-allocation vs. long-term allocations - see http://mailman.mit.edu/pipermail/krbdev/2015-July/012406.html
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rmainz@redhat.com
\__\/\/__/ IPA/Kerberos5 team
/O /==\ O\
(;O/ \/ \O;)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
