vyodaiken

This is a common argument, but it is flat out wrong. If, as claimed, compilers have complete freedom of choice about how to handle UB, they have the choice to e.g. make this behavior depend on the processor architecture. Compiler developers are choosing to use UB to make C semantics defective.

C is designed to allow programmers to insert or remove checks as performance tuning. Compiler UB "optimizations" that remove that ability from the programmer make the language unusable.

Good point. C programmers have come to assume that C is a shitty language with terrible semantics and it's their fault for not using Rust or something. They blame the language for the mess made by standards/compilers.

"static int y; /* uninitialized / _Bool cond = f(); int x = cond ? 2 : y; / Is it legal to fold this to int x = 2; ? / Hopefully, you'll agree that that is a reasonable optimization. Now consider this code:"

Do not agree. That's not an optimization it's just false reasoning. Reasonable would be to either ignore it so the code depends on the uniitialized data, whatever it is, or to flag an error. Also according to the standard, static variable of arithmetic type are initialized to zero by default so there is no UB at all.

Second example has the same problem.

Third example has, for example, assumptions that C does not let the compiler make e.g. that z is a restricted pointer. Imagine that f(int c) { z = getsamepointer(); z +=1;return *z; }

And none of those optimizations existed in the 1980s.

I see this argument a lot, but it's silly. I don't have to care whether gcc changed the settled semantics without notice or documentation out of sincere belief that they were helping or out of a desire to beat a benchmark that doesn't matter to me, or out of habit. It's not the intent of the compiler authors that matters, but their disregard of the needs of application programmers.

One issue is that under the prevailing interpretation, the existing semantics is not reliable. You do not know when or if the compilers will take advantage of UB to completely change the semantics they are providing. That's not tenable.

The current situation is not good for compiler writers either. But nobody has ever shown that either C programmers want to sacrifice safety for "optimizations", or that these UB optimizations actually improve performance of anything.

It is completely useless to allow compilers to assume false things about the code they generate.

e.g. removing a check for for overflow is definitely NOT ignoring the behavior. Deleting write because it would be undefined behavior for a pointer to point at some location is also NOT ignoring the behavior. Ignoring the behavior is exactly what the rationale is describing when it says UB allows compilers to not detect certain kinds of errors.

Returning a pointer is certainly a use. In any event, the prevailing interpretation makes it impossible to write a defined memory allocator in C.

If a program writes through a dangling pointer and clobbers a return address, the programmer made an error and unpredictable results follow. C is inherently memory unsafe. No UB based labrynth of optimizations can change that. It is not designed to be memory safe: it has other design goals.

What are the odds that anyone on the Reason staff understands averages, let alone calculus?

> Most of your arguments are about freedom as such, not the economics of a free market. Slavery, women's rights, and native american land appropriation fall under this.

There is no free market in labor under the rule of "do this work or I will whip you to death or worse." There is no free market in real-estate under the "we are going to murder your entire community and take the land". You have a misleading story about economics/government which only works if you discount the brutal grotesque treatment of captive labor as if the human beings caught up in the machinery of slavery don't matter. That's not just bad history, it is morally repellent.

>a far freer market than we have today, as long as you were white

Except for the iceberg, the Titanic sailed safely. You don't know anything about the economics of US slavery - which was enormously big business and affected the entire development of the US economy.

Your theory about stealing native american land is ridiculous. There is no free market if your economy depends on piracy. You're trying to use some legalistic card trick to pretend that something is not what it is.

Married women had no property rights: therefore they could not be participants in a free market.

You have a narrative totally at variance with actual history, but it fits some ideological point you want to make. You would be better off trying to understand why your ideology is so incompatible with empirical reality. The end.

The whole thing is incorrect. You claim "The U.S. came close to a free market at the time of its founding and has become progressively more unfree since" even though "at the time of its founding" the US economy significantly depended on slave labor and wholesale theft of land from Native American tribes. What kind of free market operating without force do you have when millions of human beings are under the lash? As for your excuse for the theft of Native American land, the inability of the native Americans to defend their property or to organize property law as Europeans did in no way makes the violent theft of their land some operation of free markets without coercion. As for women, look up "coverture" (https://ap.gilderlehrman.org/essay/legal-status-women-1776%C... ) Your whole story is a fantasy.

>BTW Paxos also has a leader - this is what makes these protocols efficient.

That's the funny part of Paxos. Paxos is specifically sold as a multi-proposer protocol. The most subtle and hard to understand part of the protocol is the clever 2 phase proposal election with value inheritance. But it's all pointless because in order to make the system work you need a single coordinator you elect using timeouts or reliable message protocols.

>There are almost no paxos implementations, correct or otherwise, making it harder to reason about its popularity and ergonomics.

If I was cynical, I might guess that the purpose of Paxos these days is to generate expenses and technical failures for Google's competitors.

I think the answer is that in the late 80s/90s, academic CS decided that the important topics in this area centered on completely asynchronous networks. The super famous, but trivial, FLP "theorem" gave a respectable foundation for work in the area (even though it pretty much says, you can't get anywhere with a completely asynchronous network). There was a lot of very interesting work prior to this period that was just discarded. For example Liskov's paper on using timeouts

https://www.yodaiken.com/2018/07/16/practical-uses-of-synchr...

Viewstamps depends, implicitly, on timeouts. You send a message a number of times and if you don't get a response, you abort. In the completely asynchronous world, there is no way to do that.

You don't need Paxos at all. In fact, you should read Liskov's paper https://www.yodaiken.com/2018/07/16/practical-uses-of-synchr...

The key is to decide whether timeouts work in your network. If timeouts don't work and you don't have some reliable message protocol, then nothing works. If timeouts do work, then a completely simple obvious brute force algorithm works. In this algorithm, we have leader/coordinator election. The leader then polls the acceptors for the highest sequence number of a committed message and recovers all missing messages. Then the leader starts sending new messages - increasing the same sequence number. The old leader, if it recovers should know that its lease as leader has timed out, but if it does not it cannot get acks from a majority of acceptors for a new message because a majority have signed on to the new leader. There is no "value" competition - only a competition for the id of the new leader during leader election. We don't need Paxos at all.

"A free market exists when force is barred. The U.S. came close to a free market at the time of its founding and has become progressively more unfree since"

A large part of the population was forced to enage in hard labor for nothing under a terroristic regime - creating an enormous amount of value (by 1860, the "mortgage" value of US slaves was greater than the value of the entire industrial plant). Women had no property rights. There was an ongoing genocide of native americans and wholesale siezure of their property.

stage 1: elect a single coordinator (which you have to do with paxos anyways) stage 2: the coordinator sends each message over and over until it has accepts from 51% of acceptors or it times out and starts a reformulation of the acceptor set

If an acceptor does not receive a message from the coordinator over a sufficient period,it times out and tries to trigger a new coordinator election

Coordinator election: try for t time units to get a majority of acceptors to accept your proposal to be coordinator. give up on timeout or notification that there is a running coordinator.

This is the simplest method and not the most efficienct, but it is both live and safe.

Chang/Maxemchuk propose to make stage 2 more efficient that acceptors be arranged in a cycle and messages from the coordinator be numbered sequentially. Then each acceptor takes a turn to broadcast its accept but only does it if it has seen all prior (lower numbered) messages and their accept message responses. on each cycle completion, the coordinator can commit the first message in the cycle.

It's super simple. You have a network where sometimes messages don't get delivered. One agent (process, site ... ) sends a message m to a collection of other agents distributed around the network. How can the sender be sure that at least some number of the intended recipients got the message. This is what databases do with commit protocols. Essentially the same problem is generalized for so-called distributed consensus protocols - of which Paxos is a very complicated example. The simple solution is that the sender keeps sending either until a timeout happens or it gets ack messages from whatever number of recipients it needs to be sure got the message. That's it. If the recipients are executing a deterministic state machine and the messages are the inputs to that state machine, you can be sure all the ones that have received the same messages in the same order are in the same state.

I wrote a little simulation. Paxos rarely gets stuck with a small number of proposers/acceptors, but jams up solid once you get to, I forget, 10 or 20. Here it is:

https://www.yodaiken.com/wp-content/uploads/2016/10/paxos.pt...

Embarrassingly badly written Lua code for the simulator https://github.com/yodaikenv/consensus

The key to me is that once you accept the need for leader election, you have much simpler alternatives and can toss away the rest of paxos.

Paxos livelocks (doesn’t work). So Lamport suggests electing a coordinator via timeouts(since flp is a joke). But if you can elect via timeouts you don’t need paxos at all. QED

The really annoying thing is that "Paxos Made Simple" begins by outlining the algorithm as a solution for a completely async network (unlike real networks) but then towards the end, just blows that off and falls back on timeouts. But if you have timeouts there are far simpler and more efficient solutions.

FWIW: FLP is a silly "theorem" that says "if you can't tell the difference between a system that has crashed and one that is slow - why then you can't tell the difference."

Paxos is wrong, as Lamport explains on page 7 of "Paxos made simple", but apparently nobody reads that far.

great

That's nice. So when the Zetas take your land, it's all good?

So right to property means I can burn tires on "my" land and pour benzene into the water table? And property titles are maintained by magic pixies and enforced by private police?

And I love the idea that crying fire in a theater is exercise of a right. I suppose fraud is simply exercising rights?

Even the C standard still pays lip service to the notion of C as high level assembler. The notion that C should be an abstract high level language insulated from the machine is foreign both to the language design and usage. C is not designed to be memory safe, for example. The intent of implementation dependent and undefined in the C specification was to make explicit that the compiler was not entrusted with safeguarding the programmer against non-portable use. The bizarre theory that this can be interpreted as a license to sabotage the programmer in the case of non-portable use makes C unusable for its intended purposes - even if it make it possible to wring performance from terribly written benchmarks.

I can't imagine it is ever the intent of the programmer that if(i+1 < i)x be there simply as decoration to be removed by the compiler. If the compiler can deduce that the test will evaluate as false (or true), it is perfectly reasonable to optimize by deleting the line (or the check, in case of true). But this should be sound deduction. For example, if the target processor traps on overflow, the compiler can deduct that the conditional is always false. But what GCC/Clang do now is (a) generate machine code on x86 and ARM that does wrap, and (b) transform code on the axiom that ints will not wrap!That is, they take "false" for a theorem.

Why do you assume we want either Pascal ("wrapping semantics") or random-"optimizations". Those are not the choices. It's actually very easy for the compiler to detect that it is a check to avoid overflow, it's the text of the program. You don't need to compile with wrapping semantics: the compiler generates code that actually does overflow the counter. All you need to do is to stop using invalid reasoning of the type: We assume that overflow cannot happen, yet generate code in which it does happen.

>OK, then that definition excludes register allocation as a permitted optimization

Oh come on.