Adopt C11 as base language #86
Description
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=578
53
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?
Original issue reported on code.google.com by danbonachea on 14 Sep 2012 at 6:33