Your C is not standard C

      Some operators (the unary operator ~ , and the binary operators << ,
  >> , & , ^ , and | , collectively described as bitwise operators)
  shall have operands that have integral type.  These operators return
  values that depend on the internal representations of integers, and
  thus have implementation-defined aspects for signed types.

Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.

> N3863

Hm?

    Because implementation-defined behavior relies on the definition of unspecified behavior, it
    means that implementation-defined behavior requires two or more possibilities to be defined in
    the standard. However, a brief look at its uses in the standard clearly shows that there isn’t
    always a list of potential behaviors to pick from.

    N3783 5.2.1.2p1.1: Physical source file multibyte characters are mapped, in an implementation-
    defined manner, to the source character set (introducing new-line characters for end-of-line
    indicators) if necessary.

    N3783 5.2.1.3p1: A conforming implementation shall produce at least one diagnostic message
    (identified in an implementation-defined manner)

    N3783 5.2.2.2p1-2: In a freestanding environment (in which C program execution can take
    place without any benefit of an operating system), the name and type of the function called at
    program startup are implementation-defined.

e.g.

   MOV AX, 1
   MOV CL, 33
   SHL AX, CL

Given a choice, I'd prefer performant bit-twiddling in exchange for UB in cases that never occur in practice.

At least make it "change of the sign bit is UB" — if 0 shifts into the sign-bit of a positive number, or 1 shifts into the sign-bit of a negative number, that shouldn't be UB. This would make left-shifts of negative numbers well-defined, their behaviour being that of two's complement numbers. And C23 already demands two's complement from the implementations, doesn't?

> signed overflow UB can be turned into traps using sanitizers.

Well, yeah, sure, but shifting -1 one place to the left doesn't overflow, it produces -2; only shifting INT_MIN or something up to and including INT_MIN + (INT_MAX/2) would overflow.

    4) The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
    are filled with zeros. If E1 has an unsigned type, the value of the result
    is E1 × 2**E2, wrapped around. If E1 has a signed type and nonnegative value,
    and E1 × 2**E2 is representable in the result type, then that is the resulting
    value; otherwise, the behavior is undefined.

    5) The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
    unsigned type or if E1 has a signed type and a nonnegative value, the value of
    the result is the integral part of the quotient of E1 / 2**E2. If E1 has a
    signed type and a negative value, the resulting value is implementation-defined.

That's something pthreads do and CSP doesn't.

> you need a memory model with compiler support. Even if you exclusively use mutexes.

If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."

At least to me, section 4 seems to imply that the "assumption" is a bit more than just that. For example:

> We know of at least four optimizing compilers (three of them production compilers) that performed this transformation at some point during their lifetime; sometimes at least partially reversing the decision when the implications on multi-threaded code became known.

i.e., there are real-life instances of the lack of compiler/language support leading to miscompilations. Yes, that example is talking about threads, but I think a similar argument should apply to atomics.

> I gave you an example of atomics being handled by a library

The thing is that nothing in that man page indicated to me that that library wouldn't be subject to problems similar to that described in Boehm's paper; e.g., for all I know that library is the Plan 9 moral equivalent of pthreads and is subject to similar problems pthreads is when a non-thread-aware optimizing compiler is used.

> Kencc is a very "dumb" compiler that does little magic

This could (partially?) address things though. If Plan 9 always uses that compiler and if there's no interest in implementing the optimizations Boehm describes then that would obviate 2 of the 3 correctness issues Boehm describes (though that would also imply that Plan 9 uses its own dialect of C with its own set(s) of guarantees, both explicit and implied). The only thing I'm uncertain about is to what extent hardware reordering would be relevant; I thought I remember reading about that making things interesting, but I don't remember off the top of my head to what extent.

To quote Rob Pike,

"Early 1990s: Alef (Phil Winterbottom) grafted the concurrency and communications model of Newsqueak onto a more traditional compiled C-like language.

Problem: with C's memory model in a concurrent world, hard to know when to free items.

All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming."

http://go-lang.cat-v.org/talks/slides/emerging-languages-cam...

Of course no doubt that (hopefully) C compilers used for compiling plan 9 things won't break it, but...that's then talking about plan9-C, not C99, at which point you're necessarily already in the bucket of "this library relies on extra guarantees that plan9 C makes, instead of it just being a regular C99 library".

> > so you'd need to know how Plan 9's compiler/language specifies atomics.

> It doesn't, as far as I can tell. Kencc is a very "dumb" compiler

...So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't, on account of not making certain valid optimizations. Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.

Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99. As a simple example I came up with on the spot:

    static int foo;
    int main() {
      some_preparation();
      foo = 2;
      fence_probably();
      do_thing(&foo);
    }

But, if atomics exist, `do_thing` could do a relaxed store of its given foo address to a global, and another thread could then do a relaxed load of that and dereference that to get foo's value. And if the compiler decides to reorder the store to `foo` to after the fence (as a C99 compiler can), the program now has a data race that it otherwise would not.

(hell, a C99 compiler could even insert `int tmp = something; something = 123; something = tmp;` for any variable or global or field `int something`, in any place in the code (as long as `something` is known to be mutable), which'd break basically every multithreaded thing; this effectively one of the things the "Threads Cannot Be Implemented As a Library" paper mentions)

which is precisely why they can get away with a library seemingly without having to specify or coordinate anything with the compiler.