C99 Features

[Nathaniel McCallum]

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.

> 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.

> 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.

I think VLAs buys a lot.

> 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. 

Agreed. I think compound literals help a lot with data type shuffling.

>  * VLAs also don't seem to present
> issues except for the lack of MSVC support.

Of all the features, I find VLAs most valuable.

https://github.com/npmccallum/krb5/commit/9345f2b92712d39573a17b75fcae8
2bfb0f5009e

> * 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.

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

My personal preference here is the following.

Declare variables at the beginning of its appropriate scope. For
example:
context ctx;
for (int i = 0; i < x; i++) {
  foo *x;

  x = make_foo(&ctx);
  assign_foo(x);
}

Allow mixing of statements only in initializers at the start of scope:
krb5_data x = { 0, strlen(str), str };

... or VLAs:
len = get_buffer_len();
char buffer[len];

Other than that, I don't mix declarations and statements.

Nathaniel