[19198] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Chris Hecker)
Tue Jun 16 04:54:31 2015
MIME-Version: 1.0
In-Reply-To: <557FB233.3000102@mit.edu>
Date: Tue, 16 Jun 2015 01:54:19 -0700
Message-ID: <CAOdMLc1tOokQx+EoykDMP8=bS=pf3d6hf=ag_-nw8ByvgkgsDw@mail.gmail.com>
From: Chris Hecker <checker@d6.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I still build on vs2008, for what it's worth.
Chris
On Jun 15, 2015 10:24 PM, "Greg Hudson" <ghudson@mit.edu> wrote:
> On 06/15/2015 09:06 PM, Nathaniel McCallum wrote:
> > So how about it? Can MIT start using C99 features?
>
> There are four questions here:
>
> 1. Can we reasonably require MSVC 2013 for the Windows build? I don't
> know of a compelling reason why we can't, but there may be reasons I
> don't know about.
>
> 2. Can we abandon MSVC for the Windows build in favor of mingw or clang,
> in order to get VLA support? I think the practical answer here is no,
> in that we don't expect to commit the resources to investigate this
> possibility in the near future.
>
> 3. Should we allow MSVC-unsupported C99 features in code we don't
> currently build on Windows? (This includes the KDC, KDB library,
> PKINIT, and everything related to kadmin including gssrpc.) I don't
> really feel strongly either way, but it doesn't buy us a lot to allow it
> in just a few places, and the inconsistency could be confusing.
>
> 4. Are there any C99 features we don't want to use, because they don't
> mesh with our BSD KNF-inspired style or for other reasons? Going over
> the specific features you mentioned:
>
> * Designated initializers and compound literals don't seem to present
> any stylistic or practical issues. VLAs also don't seem to present
> issues except for the lack of MSVC support.
>
> * Does _Bool present any issues if it creeps into public ABIs? I found
> http://yarchive.net/comp/linux/bool.html but it's from 2009, and might
> be specific to the kernel. It might also just be confusing to have
> "krb5_boolean" and "bool" in the same code base when they aren't
> generally the same size (krb5_boolean is a typedef for unsigned int).
>
> * Our style guide discourages declaring variables in interior scope.
> The justification (which predates my involvement) has to do with
> debugging convenience and limiting function complexity; I personally
> find that code is a little easier to read if it doesn't have type
> declarations mixed in with statements. If there are good reasons to
> avoid interior scope declarations, those reasons may also apply to mixed
> declarations and code.
> http://k5wiki.kerberos.org/wiki/Coding_style/Practices#Local_variables
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
