41–50 of 231 posts
This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…
"A much better alternative is to reuse the original library and just publish a safe interface to it." I think I must reject the premise a bit, unless I misunderstand how Rust works. If you write a safe wrapper around unsafe code, is it not still the case, that if the unsafe code bombs out, it will take the safe Rust down with it, engulfed in shared flames? (Unless you spawn unsafe code in its separate process or some…
Earlier quoted context omitted.
> In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. Just a nitpick, this is only true for non-garbage-collected (or refcounted) languages. :-)
Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to let you choose where to allocate in the first place, and have obligatory heap semantics for reference types. Some compilers (including Go and Java, to my knowledge) will attempt to optimize the implementation to stack allocation when possible using escape analysi…
:-)
> A garbage-collected language wouldn't let you allocate such items on the stack in the first place.
I get your point, but I don't think this is entirely true.
When people think of call stacks in the general sense, there's a major distinction between CPU stacks and managed stacks.
For example in both Java and Go, stack allocations are determined at compile time, and heap allocations at runtime. (Obv, stacks here are not actual CPU stacks, just managed memory stacks depending on the implementation.)
Earlier quoted context omitted.
Like this: use sha2::{Sha256, Digest}; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); ?? } How do I get a string with the hash value? Which chapter of which book should I read?
As mentioned by others, you need to convert the bytes to a String. `Sha2` provides a helper function for that: `hasher.result_str()`. EDIT: sorry I don't know which docs I was looking at, I can't find it in the current version.
The title should be "how to not" rather than "how not to".
But reading code is hard, it's easier to project your sense of confusion onto your predecessor than own it yourself, and once you rewrite the code in Rust and start to understand the true complexity that the previous code had to work around, you'll leave for another job (this time with Rust on your resume).
Earlier quoted context omitted.
It really depends on your opinion on split infinitives. Both are correct.
Surely "How Not To..." is typically used when you're talking of a bad way to do something, or a way to fail - so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. It also isn't the wording used in the original article title.
Actually, this is the case. It describes the bad way (and bad reasons) to rewrite something in Rust.
> This may be problematic because it’ll require all users of our chmlib crate (and their users) to have Autotools installed. Autoconf creates a portable shell script, right? No need to have it installed just to build the project.
"portable" to different Unices, right? I'm on Windows, for example.
If you want to natively compile on a fairly recent linux with the common standard libraries autotools works well. Even though autotools was written to work around these differences, in most cases the developer didn't hook into autotools detecting that difference and so it doesn't work.
Earlier quoted context omitted.
The tree only contains configure.in, not the generated configure output, and Makefile.am, not the generated Makefile.in. You do need the entire autotools suite installed for it to build. Why they published it like this is beyond me, however. The whole point of autotools is not making your users install them (unlike CMake and virtually every other build system for C there is).
That's not true. If you build from a dist tarball, you do not need auto tools installed. You usually do if you build from a git repo, however.
"It" in my post referred to the Rust cargo package in question. The package ships configure.in, but not the generated configure. You do need autoconf for configure.in -> configure. Similarly, it ships Makefile.am, but not the generated Makefile.in for use with configure.
Note how I said "The whole point of autotools is not making your users install them".
Earlier quoted context omitted.
As mentioned by others, you need to convert the bytes to a String. `Sha2` provides a helper function for that: `hasher.result_str()`. EDIT: sorry I don't know which docs I was looking at, I can't find it in the current version.
This is helpful but in general what is a problem of having strings and trivial functions to convert something (like bytes) to strings? Maybe I am missing the point.
There are some examples of printing output using formatting strings in the RustCrypto readme:
let hash = Blake2b::digest(b"my message");
println!("Result: {:x}", hash);
If you're looking to get the actual string value rather than just print it out, then take a look at the format macro. It uses the same format strings / traits etc as println, so wherever you see println you could drop in format instead:
let hash = Blake2b::digest(b"my message");
let text = format!("{:x}", hash);