401–410 of 498 posts
For someone starting at zero, would you recommend C rather than Rust or the other way around?
Earlier quoted context omitted.
Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Your proposal would force them into having a real live range, with a stable value. See this section for an example, which shows examples of the kinds of optimizations this opens up: http://llvm.org/docs/LangRef.html#undefined-values There's also the issue that having a stable value forces the register alloc…
> Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Even specifying that they have a new arbitrary value on each access would be a big improvement over the status quo. It wouldn't allow nasal demons. Since LLVM seems to already have these semantics, it makes a good argument that it wouldn't hurt C's performance to tighten the spec at least that much. But I…
This is approximately what LLVM describes undef as, and it indeed leads to nasal demons. This description enables a single value to both pass a bounds check, and then subsequently go out of bounds!
Earlier quoted context omitted.
What is it with rewrite-the-world-in-Rust people being stridently anti-copyleft?
I don't understand it either. It's as though they want to ignore the history of free software, which simply wouldn't have happened without copyleft.
Earlier quoted context omitted.
Like many other programmers, I avoid GPL'd code like the plague. The idea that you can own an idea seems ridiculous to me, and it feels unjust to sue "random corporations" for using ideas that you published. We're standing on the shoulders of giants, and I see the GPL as a tumor that's draining the world's resources. Just my two cents.
It's not about owning an idea, like a patent is. It's about receiving payment for someone else using the code I developed. The price for using my code is that you also release your source code. If that price is too high, you can't use my code. The hard part is defining "use my code" in the context of reading my source, then using those ideas in your own project. At what point does it change from gathering an idea to…
Earlier quoted context omitted.
What is the roadmap on getting rid of the need for libc? Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.
Do you suggest they should use raw system calls? On most systems your options are either calling standard C functions or doing raw calls (not portable). Someone did start a C stdlib implementation in Rust, but it appears to be inactive: https://github.com/mahkoh/rlibc
Earlier quoted context omitted.
This is getting a bit meta, but I disagree. It would be trivial to abuse in discussions. A: Bash would be way better for SQLite, really! B: But Bash is a terrible choice because X, Y, Z, ... A: If you make those arguments, you have to prove them.
"Bash would be terrible because using it would cause a fire" Yes, arguments have a burden to make sense, and provide evidence...
Earlier quoted context omitted.
> Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Even specifying that they have a new arbitrary value on each access would be a big improvement over the status quo. It wouldn't allow nasal demons. Since LLVM seems to already have these semantics, it makes a good argument that it wouldn't hurt C's performance to tighten the spec at least that much. But I…
> What parts of the STL can be faster by treating uninitialized variables as impossible? What I'm mostly thinking of is allowing unused branches to be pruned. The STL tends to get inlined really heavily, which results in a whole pile of IR being emitted for what look like very simple operations. Based on the actual parameters and state, the optimizer then wants to prune out as much dead code as possible to reduce i-c…
Even if you can remove one of the branches because you know if the string is small, the logic of "this branch can't happen" -> undefined -> delete sounds more complex than "this branch can't happen" -> delete.
Earlier quoted context omitted.
> Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Even specifying that they have a new arbitrary value on each access would be a big improvement over the status quo. It wouldn't allow nasal demons. Since LLVM seems to already have these semantics, it makes a good argument that it wouldn't hurt C's performance to tighten the spec at least that much. But I…
> Even specifying that they have a new arbitrary value on each access would be a big improvement over the status quo. This is approximately what LLVM describes undef as, and it indeed leads to nasal demons. This description enables a single value to both pass a bounds check, and then subsequently go out of bounds!
Earlier quoted context omitted.
Well there's the rub - once you see the source code, it's tough to say you weren't influenced by it. In for-profit endeavors this kind of thing is typically done by having two separate groups of people, one that sees the competing product and writes detailed descriptions of behavior, and one that never sees the product, only the product of the first group. If you're careful about this and go to pains to keep the grou…
We're talking copyright here, not patents. If I read copyrighted C code, and rewrite it in Rust, I don't think a copyright claim can touch you, no matter how similar they are. Note well: IANAL. This is my understanding of copyright law, not legal advice.
Code is just tricky though and metaphors for books and other things often break down easily... API / module substitution copyright seems silly, but maybe only to people who understand programming or who can grasp the metaphor that copyrighting an interface is like saying any book that uses numbered chapters (instead of custom named chapters) is a derivative work of the first book that used numbered chapters. Some code "could be but one way", naming included / irrelevant (I think a lot of SO code is like this, there are very few ways to glue together certain bits of code to do small thing X in context C), some of it is more like performance art, some of it is just almost pure math, and some of it works as a whole to solve one particularly hard problem which in itself has business value, just as music has business value by solving the problem of being appealing to listen to so that people buy it. Copyright law seems ill-equipped to handle it. Strategically though, I'd go with what the lawyers advise -- a lawsuit that I win can still be more costly than just playing it safe to begin with.
Earlier quoted context omitted.
> His argument is that achieving the level of quality that SQLite has requires verification (in a broad sense) after the compiler, and that's what he does. > If you consider the goal to be producing quality-assured binaries, then you can treat UB, compiler bugs, and many other things as falling in a similar category, which are almost certainly eliminated by an MC/DC test suite. I don't think that they're eliminated b…
> I don't think that they're eliminated because dynamic testing can't eliminate everything—it only finds bugs given its test inputs. I can't think of an example of UB-exploit in the compiler that wouldn't result in different branch behavior, and thus, I think, in failure of MC/DC. But I may simply be insufficiently imaginative. John makes the point about source code in a follow-up comment, and I agree, but I also see…
What about Implementation-defined Behavior? This is (I think!) technically a subset of Undefined Behavior and it permits such things as setting values[1] to arbitrary (but well-defined!) values on various operations, such as "excessive" left shifts. What I'm saying is that a compiler is permitted to substitute IB for UB and still be conforming. So it could start to do strange things to arithmetic, etc. Does that make sense as an example of what you're thinking of?
EDIT: [1] I obviously meant memory locations... as referred to by "variables" which aren't really variables, but are really binders/aliases. But here we are.