C99 VLA (=Variable Lengh Array) helper macros... / was: Re: C99 Features

[Roland Mainz]

----- Original Message -----
> From: "Roland Mainz" <rmainz at redhat.com>
> To: krbdev at mit.edu
> Sent: Tuesday, July 7, 2015 6:33:01 PM
> Subject: Re: C99 Features
> 
> 
> 
> ----- Original Message -----
> > From: "Nathaniel McCallum" <npmccallum at redhat.com>
> > To: krbdev at mit.edu
> > Sent: Tuesday, June 16, 2015 3:06:39 AM
> > Subject: C99 Features
> > 
> > It has been 16 years. GCC has had support for many C99 features for a
> > LongTimeNowTM. Clang has had them since the beginning. Clang also now
> > has official Windows builds (as well as many other platforms).
> > 
> > Of course, MSVC still lags behind. However, they have started
> > implementing features, including the following since MSVC 2013 [1]:
> >  * _Bool
> >  * Compound literals
> >  * Designated initializers
> >  * Mixing declarations with code
> > 
> > MS has also implemented most of the C99 libraries[2] and has already
> > announced complete support for the C99 standard library in MSVC
> > 2015[3]. One of the big elephants in the room is VLAs. MS is unlikely
> > to ever support them. But, it is also MS's stated policy to only
> > incorporate C features that are required for C++[4]. I'm not sure that
> > MIT should hold back support for new C features because MS only wants
> > to ship a C++ compiler.
> > 
> > So how about it? Can MIT start using C99 features? Even a subset of the
> > features would be helpful. I particularly care about all the above C99
> > features that MS implemented plus VLAs. The latter, in particular, can
> > eliminate a lot of heap allocations.
> 
> 1. Using |bool| would be a very good idea because it allows a lot of
> optimizations with low optimizer settings. There is a possible risk of
> namespace clash with |krb5_boolean| so I suggest to use a new define like
> |krb5_std_bool| if we want it in public APIs (which we should do (question
> for myself... did the ISO C spec define a size for |bool| ?))
> 2. IMHO we should use |restrict| where possible (e.g. crypto, string-heavy
> code etc.) to squeeze out some performance
> 3. VLAs can be tricky, but usually aren't a big problem if used with care
> (I've been there with Solaris's OS/Net long ago and it was a *pain*
> politically-wise and getting all tools fixed, but these should be issues if
> the past). Main issue is to define an upper per-allocation limit which can
> be allocated via VLAs and then switch to |malloc()| if the allocation is
> larger than that limit (typically |getpagesize()*8| was considered a "safe"
> limit in Solaris OS/Net). If I recall it correctly the following code should
> handle the issues correctly (except that it should use the ISO C99 feature
> test macros to test whether VLAs are available (this will cover the
> "limitations" of the Microsoft compiler)):
> -- snip --
[snip]
> -- snip --

Attached (as "vla.c.txt") is an updated version which fixes the reported issues:
- Added support to compile with pre-C99 compilers
- Added support for C11 VLA feature test macro |__STDC_NO_VLA__|
- Fix multiple evaluations of the |size| argument in |VLA_ALLOC_ALLOCATE()|
- Make testcase more troublesome for compilers and valgrind
- Add more comments how stuff works
- Attach code instead of pasting it inline to prevent the WebMail software from messing with the code

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) rmainz at redhat.com
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vla.c.txt
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20150709/4ec3a6c8/attachment.txt