grep -irn getaddrinfo .
./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(),
./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char,
./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo`
How many places doesn't rust source code use C structures or call C APIs?
In the rust source tree, run this:
grep -irn '[^a-zA-Z0-9]c::' . |wc
615 3143 56000
279 1719 23448
Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust.
Also, extern "C" is for C FFI exports not calling C APIs. The world unanimously decided C FFI is the least common denominator, so its not like Rust can provide a different API with better safety hints.
Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable!
Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.
Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created.
They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.
"C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth.
Yes, O2 causes fire from time to time, but you can't live without it.
Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself.
There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years.
C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others.
The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion.
PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.
seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.
There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe!
You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it.
At some point, you have to talk to the computer directly (aka "unsafely"). Things like bounds checking, garbage collection, and other runtime utilities sound like great ideas until they translate to significant monetary costs each month.
Not everything is as trivial as writing GUI glue code in a nice comfy language with a magical framework. Although, most of it is.
I do a lot of low-level Rust programming and a lot of low-level C programming. I don't know what the performance penalty you're claiming exists comes from. Can you elaborate as to the specific Rust features that you claim are slow?
(Incidentally, the project I'm working on right now in Rust beats all of the existing C competitors in performance by a lot.) :)
I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal.
I was wanted to drive the point that additional abstractions are undesirable at that low level unless they can be enforced at compile time. I'm concerned by some of the magical thinking being espoused in this thread about what's actually reasonable in terms of the trade offs you can make.
In other words I was talking about safety, not speed.
I'm glad to hear Rust is out performing C though. I just wish I had a better IDE than atom...
Didn't you once mention Xcode support for Rust?
Also, my statement was not that general or vague. Maybe it could have been clearer, but it appears to have also been misinterpreted by pcwalton.
I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust.
So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it.
I can't participate in a community that's fundamentally hostile to skepticism.
But previously you said "because it can't be safe at such a low level without a performance penalty" which clearly implies performance is part of your argument. This is what I was talking about in my other reply, which mentioned "without narrowing the scope or clarifying your intent".
> I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust.
This is more about backing up claims with concrete examples. pcwalton is a Rust developer, I'm sure he would be very happy to hear a specific shortcoming he wasn't aware of, or was undervaluing. That's how improvements are made.
> So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it.
There may be some of that, but I also see a lot of rust community members trying to explain where people's assumptions are wrong, and it being taken as being antagonistic. The fact that Rust has some compile time checking that could actually make some of the low-level code faster is what I think is being alluded to by pcwalton. Of course there will be things that rust won't catch, and will need to be done in both C and rust, and there's things that other languages may catch that rust doesn't and vice-versa.
> I can't participate in a community that's fundamentally hostile to skepticism.
That's an interesting way to put it. You've made assertions, and when asked for clarification or evidence, began your response by calling the other commentor's motives into question (is it a reasoned response, or was it overly emotional because they were "defensive"). Asking for evidence of assertions is skepticism, and to balk in face of requests to do so is actually what I would consider being defensive.
To be absolutely clear, I don't think you would have been downvoted if you didn't start your reply with "A little defensive, maybe?". I didn't downvote you, but my initial assumption was that the downvoting I saw was because of that.
I guess I felt I was being attacked for a point that I wasn't even trying to make. That is, I was responding to you under the impression that I had clearly said something differently than what was interpreted. All without taking the time to read over my own post carefully. Then I got overly emotional which resulted in us talking past each other unproductively and rude remarks on my part.
So I'm sorry for being a melodramatic jerk yesterday. I am actively working on my self control and civility, but I definitely made a mistake here. Hope you have a good day.
I'm not defending anything, You didn't supply clarification of your point. You were asked for clarification, and provided someone else's experience (anecdotal) counteracting claims (which weren't even anecdotal, they were unsupported assertions), and you started out as classifying that response as defensive.
> notice how you assume I don't know the difference between static analysis and compile-time safety.
I said "I also see a lot of rust community members trying to explain where people's assumptions are wrong" immediately prior to that. I thought it was obvious I was talking in the general sense. I don't know what you do and don't know, but I'm not sure why you think it's valid to be upset because someone assumes this one way or the other (which to be clear, didn't happen here) when you've shown little or no evidence yet as to what you do or don't know about it. It may be the rust community stereotyping others, but without stats as to whether the people the stereotype has been applied to have it applied correctly it's hard to know whether it's useful or harmful, regardless of how it applies to you in particular.
> Notice how you assume that I must be generally uninformed or less intelligent because complete faith in Rust's importance is a self-evident truth.
Not knowing something doesn't make someone less intelligent. If you are conversing under the assumption that everyone will assume you know at least the same amount as them about every topic that is brought up, else you have right to be offended, I'm not sure how we can continue. That's not an environment I want to have a discussion in.
> Well, now that's it's happening to me personally vs just reading it. Fuck this community. It's collectively a socially inept nightmare. I'm done with caring about Rust. I was really enjoying it. After today and Reddit, I can't take anymore of this smug bullshit.
All that's happened here is you made statements and refused to back them up while at the same time you called someone else's motives into question for asking for clarification. I think it's obvious what is going on, but I'm not in your shoes. I don't think people aren't trying to be assholes you you (at least I'm not, or not trying to be one), and while you may be upset, I hope you don't leave for good. however you've interpreted my comments, please be aware that not a single one was written with the intent to upset you, or call into question your character or intelligence in any way. I can only point towards my own experience, here and elsewhere, where my state of mind greatly influenced how I read a statement and any replies to me with regard to that conversation, and think that possibly the same thing is happening here with you. That itself may come across as a smug asshole-ish thing to say depending on how you interpret it, or even my assumption that my observations apply to you. All I can do is state that my desire to be helpful after your prior statement is sincere.
That said, how else do you correct someone in the case their statements are provably false?
Edit: Whoops, "probably" was supposed to be "provably" :/
> it can't be safe at that low level without a performance penalty.
Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block.
That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.
But not bounds checks, which are unfortunately what you need with respect to buffer overflows.
A bit higher up:
It was clear when Hoare stated on his speech in 1980:
"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."
... which directly contradicts the "no one" part.
Speed is all that matters, I actually learned that from Graydon's blog:
Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it has a really good chance at disrupting the embedded space.
To the vast majority of people and organisations writing software, performance of the software, to within an order of magnitude, just isn't a big deal.