Strengthen typechecking on upc_atomic_[strict,relaxed]

[GoogleCodeExporter]

We've been doing alot of recent work with the spec 1.3 optional atomics API, 
and I have some design feedback based on recent experience. Overall the API 
seems powerful, expressive and flexible to both clients and implementers. 

However, an annoying design weakness of the current API is the lack of useful 
typechecking on upc_atomic_{relaxed,strict}. The API makes far too easy to make 
subtle mistakes like this:

#include <upc.h>
#include <upc_atomic.h>
#include <stdint.h>

shared int64_t sum = 0;

int main() {
  upc_atomicdomain_t *dom = upc_all_atomicdomain_alloc(UPC_INT64, UPC_ADD, 0);

  int val = 1;
  int fetch;
  upc_atomic_relaxed(dom, &fetch, UPC_ADD, &sum, &val, 0);
}

This simple program contains no cast expressions and passes the typechecker, 
but nevertheless contains a serious type error that will corrupt stack and heap 
memory (in ways that are system specific and may even go unnoticed on some 
configurations). The bug is rather obvious when written like this, but sadly is 
an easy mistake to make when the declarations are spread out in a large 
program. Other variants are possible, whenever any of the five types 
(domain_alloc upc_type_t, typeof(*target), typeof(*fetch), typeof(*operand1), 
typeof(*operand2)) do not all perfectly match. Worse, the design of the API 
means the problem cannot be diagnosed by the library, even at runtime, without 
some hefty compiler assistance (although I do think this is an alternative 
worth investigating).

Atomics are admittedly a tool for "sophisticated" users, but I fear the 
complete lack of static type checking on the tool we're handing them implies 
more pointy edges than even a veteran UPC programmer should be expected to 
navigate. Typeless interfaces are common in C (eg memcpy, upc_memput), but in 
those cases the user has specifically elected to use a typeless byte copy API 
(and the nbytes parameter forces them to think about bytes at every call). Our 
atomicdomain alloc call gives the superficial illusion of presenting a typed 
interface, but there is no useful type checking at the domain usage point, and 
the user has no strongly-typed alternative to accomplish the same task.

Solutions I've considered:
1. Use C++ templates (joking, but would actually help here)
2. Use compiler help to supply actual argument type information to the use 
library call for checking at runtime (only helps while using high-quality debug 
implementations)
3. Clone the upc_atomic_{relaxed,strict} entry points once per upc_type_t to 
accept well-typed arguments (and deprecate the current typeless version). This 
option would also allow us to take operand1/operand2 by value (a separate 
design question).
4. Use C11 type-generic functions to do the same thing as #3 without polluting 
the function name space (this is how the C11 atomics solve the same problem)

Original issue reported on code.google.com by danbonachea on 15 Apr 2014 at 9:47