Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

I think the most important point of Friendly C is not to define the behaviour for what would otherwise be undefined, but to define a behaviour; from this point of view, it would be unnecessary to argue over the examples he mentions like memcpy() vs memmove() and integer shifting --- it only suffices that every implementation define the behaviour, and what that behaviour precisely is can differ between them. A lot differs already between platforms, and so all this basically means is to document those differences. This agrees with the spirit of the language as a "high level assembler", removes all the undefinedness, and would be entirely unsurprising to most programmers.

The situation gets worse when we start talking about a friendly semantics for races and OOB array accesses.

I don't have anything to say about races, but OOB array accesses should simply do what you'd expect the hardware to do: attempt to access memory at the location the array indexing equation gives. It may segfault, or it may access some other contents in memory. That's what any C programmer would probably expect.

You have to look deeper for the OOB array access question. For example, imagine I have code like this:

  if (a > 1)
    b++;
  array[b] = 0;
  c = a + 10;

Under your suggested semantics, can the compiler use the value loaded from `a` at the point of the if() statement to calculate `a + 10`? Or does it have to emit a reload of `a` after the array access, in case `array[b]` was an OOB access that overwrote `a`?

How about treating it just like another thread accessing the values? So yes in the general case, no if you put in memory barriers or atomics.

Race conditions are generally treated as "you get undefined behavior" for much the same reasons.

I mean race conditions on actual hardware, not the way the standard abandons all hope yet again.

Stale reads don't require total chaos.

I'd say that it doesn't have to read 'a' again because these are separate variables and there's no requirement for 'a' and 'array' to be contiguous, or for that matter 'a' being in memory at all instead of just being in a register. An OOB access could overwrite the memory storing 'a', but I think this case of relying on the ordering and location of objects in memory is just not something any C code would ever have to do.

You're already allowing undefined behaviour then. Very confusing bugs could result - e.g. the value of 'a' might be different from what it looked like in a debugger, because the array access changed it in memory but the copy in the register hasn't changed.

I'm not seeing the deeper question, whereas what 'userbinator' said still makes sense to me.

The compiler's implementation defined behavior would simply be "if you tell me to write a value to an address, I'll create assembly that tries to write that value to that address". That's all. If this address is outside the allocated range of the array, there is no guarantee that it's safe that write this value, or that it won't break something else.

So in your example, no, the compiler is not required to reload 'a'. The compiler is allowed to presume that the array[x] syntax will have no affect on the value of a local variable, whether that variable is stored in a register or on the stack. The compiler is not guaranteeing safety, just best effort.

When you're saying that the compiler should be allowed to optimise under the assumption that OOB array accesses don't clobber other variables, this means that OOB array accesses can make very weird things happen indeed. For example:

  if (a > 1)
      b++;
  array[b] = 0;
  if (a > 1)
      foo(a);

We might see foo() called with argument 0 when that's apparently impossible - the OOB write has apparently "reached forward" (it can also "reach backward").

This is why it ends up just being "undefined behaviour" - to do better either you have to somehow exhaustively document all the kinds of weird things that can happen ("it writes to the memory" isn't enough, because of the way that can interact with the optimiser) or you have to unreasonably constrain the optimiser.

    I don't have anything to say about races, but OOB array
    accesses should simply do what you'd expect the hardware
    to do: attempt to access memory at the location the array
    indexing equation gives. It may segfault, or it may
    access some other contents in memory. That's what any C
    programmer would probably expect.

The problem is that defining OOB array access this way means throwing out pretty much every semantic guarantee from the rest of the language. There is really no friendly way to define writing an arbitrary value to an arbitrary location. By way of example, pretty much every (non-embedded) C implementation since 1972 supports recursion by writing an address of code to execute to memory. If you have semantics allowing a programmer to write to that location, then you can start executing literally any piece of code you want to. On some platforms like x86 you can execute starting in the middle of an instruction.

For example, "return" would stop meaning "execution resumes at the callsite of this function" and instead mean "execution resumes at the callsite of this function or maybe somewhere else if someone wrote to arr[-5]". The article makes a big point about the controversy of giving memcpy() the semantics of memmove(); how would you like the semantics "memmove() unless a concurrent thread is running, in which case anything might be written to dest and src might be overwritten."

Reply on news.ycombinator.com