Remove references to "C99" in specification

I'm assigning this to Scott because he just moved/copied this text, although draft 2 had the same defect before he touched it.

Our current draft includes text:

The pair \allocate and \deallocate allocate and deallocate dynamic memory from the shared segment, and are analogous to C99 {\tt malloc} and {\tt free}. They do not call C++ constructors or destructors. A user may call these functions directly, or use placement new, or other memory management practices.

And now has a subsection titled "C99 variants"

I don't think we should use the phrase "C99" in our normative spec for several reasons:

It's imprecise. C99 is a colloquialism for the official document ISO/IEC 9899:1999 (E). If we really need to reference that independent specification then it should appear in the bibliography with a proper citation.
The C99 specification has been superceded and is no longer available for purchase from ISO, so we should avoid references to it unless we are trying to reference the historical document, as distinguished from the current C11 standard.
Readers who use exclusively C++ or are mostly familiar with non-C-family languages (Java, Python, etc) might not understand the analogy being made here at all.
The allocation functions in C are named "malloc", "calloc", "realloc" and "free" not "upcxx::allocate" and "upcxx::deallocate". There is a vague similarity between free <-> upcxx::deallocate, although they are not compatible with each other (ie cannot be safely interchanged in code). malloc and upcxx::allocate have completely different signatures, and upcxx does not provide calloc or realloc analogues.

I think informal analogies to the C allocation model might belong in a programmer's guide, but we should excise all references to C99 from the normative UPCXX specification - just present our semantics and let the reader draw his own conclusions.

Comments (1)