Returning NULL on error is actually an excellent choice because most programs will crash if they try to use it without checking. A program, any program, crashing is better than this bug. Of course, modern programming languages have better constructs, but this was rare to nonexistent when C was started and if you think C is going away anytime soon you're delirious. musl's decision to change the return value to "*" is ununderstandable and likely intentionally evil.
> musl's decision to change the return value to "*" is ununderstandable and likely intentionally evil.
Dude, they documented their rationale. It was dumb and wrong but totally relatable. Irresponsible users were getting crashes, and I’m sorry to tell you that for a lot of library maintainers
> Returning NULL on error is actually an excellent choice because most programs will crash if they try to use it without checking.
…is not something they want to write in responses to bug reports, even though it is quite true. It’s human nature to want to prevent your stuff causing problems for others, even if the problems are fully their fault. Most people cannot and will not be Steve “so don’t hold it like that” Jobs, for fear that their decision will be just as short-sighted as his was.
In this case, that was obviously the dead wrong call. But I’ve been in that seat, and “closed: user error” for the 100th time feels bad to write. Add to that a touch of misplaced cleverness, and you get “hey…what if we just returned an impossible string instead of an error?”
Evil requires motive or malice, and I’m having trouble coming up with those in this case. These patches weren’t concealed or miscategorized a la xz, the behavior was discussed in the open. They were just, in hindsight, really poor decisions made for ordinary reasons. Hanlon’s Razor and all that.
That’s why I’ve been harping on C being trash for shared-code APIs in these comments: bad decisions are gonna happen, and irresponsible users are forever, so can we maybe use tools that require you to put on a seat belt (mandatory error handling) before starting the car?
> That’s why I’ve been harping on C being trash for shared-code API…
Agreed, but I can’t think of any other widespread ABIs that are better. Rust’s is not stable both C++ and Rust have concepts that don’t map into other languages well, so using them wholesale is a no go. So it would probably need to be a subset of those. Honestly just tagged unions would probably be enough. Maybe the solution is to get native tagged unions into C…
There is the concept of "defense in depth": having each layer of code and configuration be sane and secure. Even if you program in Rust, you should be vigilant in that sense. This kind of code amounts to removing one or two layers.
It's just that every other string than "*" would have been a better choice, including even the empty string (which would have been the next terrible choice).
My thoughts as well. It appears that such signal failures happen so often that the controllers regularly let trains run through red under verbal authorization. I don't know the exact protocols, but I would expect a driver to ask for confirmation, as happened here, and then trust the control centre. However, there is clearly a huge systemic problem, with added complexity for the controllers, and there should at least be double checks in the control centre.
The person who controls whether the light shows red or green and gives verbal authorization is the same. It's both a tool, to transmit the same information.
A person saying you have a green light when you have a red light is not the same information at all. The probability that something has gone wrong and will lead to disaster is many many times higher.
The right move here would've been to accept the suggestion to drive the train, but not accept the suggestion to drive it at normal speed. The driver should have driven at 40km/h.
It's not a suggestion, it is an order and a movement authority. That would have been nice, but the drivers are not required to make such a decision. The moment you issue a movement authority, you must assume the train operates with the max speed and distance of it immediately, and that must be safe. Train drivers do not decide for the speed and trajectory a train is going to take. They are responsible for that their train drives safely inside the movement authorities given to them, they are not able and hence not responsible to ensure the safety of the network. They are more equivalent to a car mechanic, not to a car driver.
"not high-speed" != "not line of sight" High speed is the speed when you can no longer safely drive by signals, not the speed when you are not able to safely observe the breaking distance. Trains are not supposed to operate under the latter (normally).
Depending on where, there can be lots and lots of small crossings. The cameras themselves might not be that expensive, but keeping them in working order is very nontrivial.
There is also the issue of recognition software that doesn't have too many false positives, and properly tuning it for each crossing, in all light situations. The amount of time and work needed can really be very large. I'm not against it though. Some pilot projects would be a good idea.
Camera security use to be a guy looking at 20 TV's. Then came motion detection. Today we can do much more of course. You would have a set of certainly not good situations, a set of certainly good and a set of things a human should look at.
It's of course fine to automatically shut down a few trains per year if it doesn't create a dangerous situation in it self.
"Directly" is way too strong. Yes, it may have been a factor here that the train that remained standing still was from another operator, but there are many more important factors at play, the main one being apparent lack of safety mindset of the controller. In other European countries with even more operators, the safety record is not commensurably worse.
It is though. It's like the electricity market. We try to liberalize it, we see it doesn't work, so we add regulations and regulators (here the "controller"), and each time there is a failure, we blame regulation or regulators, or both. Sometime when it's too egregious we blame the particular company that was caught fucking up, because blaming the system that allows such fuck ups would cost to much: ideologues in power agreeing to the idea that maybe, market do not work everywhere.
Proper training focuses specifically on those exceptional situations (like it does for airplane pilots), with strong emphasis on always falling back on safe procedures. Even so, you can't cover 100% of possibilities.
When on verbal authorization, controller discipline is probably more important than driver discipline. And I really hope they don't do that at 300 km/h.
reply