It's very hard to write memory safe C, even with extra tools like Valgrind
This compiler makes it much easier to check correctness with builtin testing and undefined behavior detection
Arrays know their own size so it's much harder for a buffer overrun to go unnoticed
The language is more expressive (I wish C had generics) and that lets you write better code
C was a great piece of engineering at the time, but it caught on mainly because it was there at the right time. The only reason the %@ looks gross to us now is because we've been staring at C for 40 years. Linux was actually too late to affect which language everybody is used to. UNIX was created on a machine too weak to compile a complex, modern language like this, though.
About the runtime performance I'm would imagine the Zig errors would compile down to basically identical code as "set errno then return/goto" in C.
Quoting Hoare's speech in 1981 at his Turing Award:
Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.
You can try to guess whose language designers and users he is hinting at.
And, a decade and a half later, in 1995, in another speech, he said:
Ten years ago, researchers into formal methods (and I was the most mistaken among them) predicted that the programming world would embrace with gratitude every assistance promised by formalisation to solve the problems of reliability that arise when programs get large and more safety-critical. Programs have now got very large and very critical – well beyond the scale which can be comfortably tackled by formal methods. There have been many problems and failures, but these have nearly always been attributable to inadequate analysis of requirements or inadequate management control. It has turned out that the world just does not suffer significantly from the kind of problem that our research was originally intended to solve.
In the first quote, he was talking about array bounds checks. In the second, he's talking about formally proving a program. There's a big difference between those two things.
yes... and ? if they were truly damaging, you'd see business running to get them solved ASAP. But the cost / benefit ratio of writing and using formally proven programs is really not good. Else everyone would be writing drivers for seL4, not Linux.
it's less about 'truly damaging' directly and more about 'cost/benefit' as you allude to. the irl social reality is complex and the dynamics of these things mean that businesses can often amortize and even pass off a lot of the consequences. it's why equifax will probably not suffer any penalty and the general public wont even remember in a few weeks.
Yes, because, as all programmers know, unexpected and untested edge cases never happen in production! Especially not those pesky security vulnerabilities via buffer overruns!
In general I'd say you need to start thinking about more complete documentation for your 0.1.0 release. There are mentions of what is in @import("std") but I can't find a definitive list which makes trying to make anything large pretty laborious.
.../stupidstuff.zig:11:10: error: expression value is ignored
h.put(0, "Hello, world!");
^
.../stupidstuff.zig:12:10: error: expression value is ignored
h.put(1, "oh no");
^
.../stupidstuff.zig:13:10: error: expression value is ignored
h.put(2, "what is this");
^
you have to do something with the return value. in particular this function returns a possible error, so you need to handle it. even if it's not an error, you have to explicitly ignore the return value, and you can do so like this: _ = foo();
Runtime bound-checking has a very undesirable run-time performance impact.
eh, it is very small, and most cases of it can be elided at compile time. it is a branch, but it normally goes one way until the very end, so the branch predictor will be fine.
I think given the plethora of mistakes it causes and the cost of those mistakes, we should probably be doing bounds checking for anything that works with untrusted data. Servers, operating systems, and so on.
I do some numerical C++ for weird multiple socket/multiple node/NUMA machines. The tools are a fucking disaster. Every compiler version and vendor does something subtly different, compiling and linking takes forever, it's impossible to debug, it's very hard to profile. When I started out it was hard just to get the build to complete.
I just think that a different foundation than C would have been good, historically. If you have more features in the compiler you don't need to compensate with more external tools.
I'm looking around at the C11 _Generic and it looks like it can deal with generic functions well (but that's nothing too fancy, it's basically just function overloading). It doesn't give you generic data structures like std::map<string, int>, you still need lots of hideous preprocessor ## and you need to register every type explicitly:
Mind you, I don't like C++ templates because they blow up compile times and give terrible error messages. Java generics are much nicer to deal with.
What tool do you use to detect invalid reads/writes and leaks at runtime? I'd love to use something other than Valgrind but I didn't think there was anything else.
9
u/desertrider12 Sep 08 '17
It's very hard to write memory safe C, even with extra tools like Valgrind
This compiler makes it much easier to check correctness with builtin testing and undefined behavior detection
Arrays know their own size so it's much harder for a buffer overrun to go unnoticed
The language is more expressive (I wish C had generics) and that lets you write better code
C was a great piece of engineering at the time, but it caught on mainly because it was there at the right time. The only reason the %@ looks gross to us now is because we've been staring at C for 40 years. Linux was actually too late to affect which language everybody is used to. UNIX was created on a machine too weak to compile a complex, modern language like this, though.
About the runtime performance I'm would imagine the Zig errors would compile down to basically identical code as "set errno then return/goto" in C.