C99 Features

Benjamin Kaduk kaduk at MIT.EDU
Sat Jun 20 15:48:41 EDT 2015

Hi Nathaniel,

I think you may be operating under some misconceptions regarding how
kerberos for windows is built.  (More inline)

On Tue, 16 Jun 2015, Nathaniel McCallum wrote:

> On Tue, 2015-06-16 at 01:20 -0400, Greg Hudson 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.
> MSVC 2015 will be released soon. MSVC 2013 seems reasonable given that
> users who don't wish to use it have a free (freedom and beer)
> alternative: clang.

At least some new VS releases require modifications to the KfW build
procedure, in terms of how a shell with the proper build environment is
obtained; they are not drop-in replacements for each other.  The official
KfW builds are currently done with VS 2010, and the windows README should
be sufficient to get someone started with VS 2012.  I think I have been
able to get the build working with VS 2013 but not had time to document
any changes needed; I have not tried VS 2015 at all.

Furthermore, because the MIT Kerberos.exe application uses the Microsoft
Foundation Class library (and possibly other reasons as well), the free
versions of VS are not sufficient to compile KfW; paid versions run
hundreds of dollars.  For that reason, many consumers are still using
older versions, since there is a real barrier to upgrading.  Requiring VS
2013 or newer would require these users to spend money on a new compiler,
which seems like a factor that we should take into account in our

> > 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.
> I don't think MIT should do this. I think MIT should require MSVC 2013.
> Users who can't use MSVC 2013 should investigate mingw/clang.

KfW is not just normal C application/library code; it integrates with the
aforementioned MFC library, and additionally (as of the 4.1 series) with
more modern UI frameworks provided by Windows.  It is far from clear that
the availability of clang as a compiler would eliminate the need for some
version of VS to be present, for these ancillary libraries and support
tools, and the build infrastructure is not necessarily robust to mixing a
compiler from clang and other tools from elsewhere.

I do not think that "just try clang" is a reasonable thing to ask of
someone else; investigating the compatibility of KfW with clang is going
to require a substantial amount of time.  I don't have that time, myself,
but would be interested in the results if you were to undertake the task.

> > 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:
> >
> > * 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).
> I don't care either way on this one.

I would prefer to avoid having _Bool in public ABIs, as there is some
subtlety involved in its use.

> > * 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_variable
> > s

Requiring declarations at the function scope can also serve as a motivator
to keep functions short :)


More information about the krbdev mailing list