Adopt C11 as base language

Originally reported on Google Code with ID 86
The C 2011 standard [ISO/IEC 9899:2011] was ratified in May 2011, and is available for
purchase here:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=57853

A near-identical draft is available freely here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

The C99 standard has been officially deprecated by ISO, as stated in the forward:

"This third edition cancels and replaces the second edition, ISO/IEC 9899:1999"

Further, it is no longer even possible to purchase legitimate copies of the C99 spec
from ISO, they have been removed from their online store. This places UPC in the awkward
position of specifying against a base language document that technically no longer
exists.

I believe we need to move towards adopting C11 as the base language for UPC, ideally
in 1.4. This thread is intended to start discussion about what's involved in making
this happen for the spec and implementations.

As a starting point, here is the summary provided by ISO about major changes introduced
in C11:

— conditional (optional) features (including some that were previously mandatory)
— support for multiple threads of execution including an improved memory sequencing
model, atomic objects, and thread-local storage (<stdatomic.h> and <threads.h>)
— additional floating-point characteristic macros (<float.h>)
— querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
— Unicode characters and strings (<uchar.h>) (originally specified in
ISO/IEC TR 19769:2004)
— type-generic expressions
— static assertions
— anonymous structures and unions
— no-return functions
— macros to create complex numbers (<complex.h>)
— support for opening files for exclusive access
— removed the gets function (<stdio.h>)
— added the aligned_alloc, at_quick_exit, and quick_exit functions
(<stdlib.h>)
— (conditional) support for bounds-checking interfaces (originally specified in ISO/IEC
TR 24731−1:2007)
— (conditional) support for analyzability

Many of these new features are conditional (ie optional), therefore C11/UPC implementations
can simply omit them and still remain compliant. Some we can simply recommend should
omitted from all UPC implementations, specifically the new optional threading support,
which doesn't play nicely with the PGAS model. It would be nice from a learning-curve
standpoint if our new atomics library (issue 7) followed the general form of the C11
atomics, but those are also optional and thus can be safely ignored.

My review of the remaining C11 features introduced by that spec didn't uncover anything
that seems fundamentally in conflict with anything specified by UPC. On the contrary,
most of the features are purely convenience features added to the serial language and
should be completely orthogonal to the UPC extensions. Many of them just provide standardized
names for vendor-specific C99 compiler features that are already widely implemented
(and by extension already available in many UPC implementations). In some cases C11
actually *weakens* the set of required features relative to C99, including some features
that have limited support in current UPC implementations (notably <complex.h> and variable-length
arrays). As a result it's possible some UPC implementations are actually closer to
strict compliance with C11 than with C99.

Questions that I think need to be answered:
1. UPC vendors: are your compiler teams already working on developing C11 compliant
C compilers?
2. If so, would those C11 extensions automatically or easily be reflected in your UPC
compiler offering, or is a parallel effort required to provide the C11 features in
your UPC compiler?
3. Which of the C11 required features (if any) would cause difficulty for UPC implementations?
3. What is the "right" upgrade path for upgrading UPC's base language document? Do
we need to issue an "intermediate" spec that allows implementations to support either
C99 or C11, or can we go straight to requiring C11 compliance in UPC 1.4?
Reported by danbonachea on 2012-09-14 18:33:40
Comments (9)
