New week, new Rust! What are you folks up to?
Working on an Introduction to Rust for Perl hackers. Decided to go down the FFI route to sell them on Rust Updates to follow.
I got a lot done on
uom (type-safe zero-cost dimensional analysis) last week. I’m working to support all types that implement
Num and finally have all tests passing for
f64. This week I’m working to extend those tests to all other types.
I’m going to work on this issue:
Hopefully I will have simple motion blur working at the end of this week.
I’m not happy with the usage of the openexr crate and would like to remove this dependency (again) if I could convert the OpenEXR image into a Radiance HDR and use image::hdr instead … I will probably create a branch where I leave the dependency on openexr in and remove it from the master branch …
I’m continuing to work on adding Rust support to lldb. I’ve got it compiling now, and it can read simple types and not crash.
I just added http/2 support to actix web. upgrade to http/2 over tls connection works, but now I’d like to add
upgrade: h2c over clear text connection
I noticed the approach I’ve taken to builders nested in other builders in
elastic isn’t very consistent, so have been playing around with some approaches to exposing inner builders generally. The result is a little crate called
fluent_builder. It doesn’t really do anything novel, and is still a bit rough-and-ready, but it’s been a good thought experiment and I probably will use it internally in
elastic to have a consistent base to build off.
I’m also hoping to have a few solid days this week to get ahead on all things libz blitz!
OK, the issue is resolved. Basic motion blur works, even though the Rust version does not match 100% the C++ counterpart (yet). Time for a new release (v0.2.4). I’m going to update the release notes tomorrow.
As for OpenEXR, what I did is using conditional compilation and a Cargo feature which is disabled by default. That way I don’t have to worry about building it on a CI server.
I’m starting to write a block cipher library, just for learning, not for production purposes.
I’m working with WebSockets (rust-websocket) so that I can eventually introduce it at work.
I have written very clean Rust code that I hope to share with you all, hopefully next week.
Next is hooking up a plotting library to it so I have some graphics instead of terminal output.
It basically polls a particular cryptocurrency exchange (synchronously, for simplicity, but would not be difficult to make it async) and you will be able to pass a closure to retrieve the particular data and do what you please.
I have wanted a good, fast desktop exchange client for a long time. Looks like I’m going to get it
I added some unit and integration tests to clerk. During this process I did some refactorings and found some bugs.
I’ve spent an unreasonable amount of time on Galil-Seiferas, but I think it has paid off. As part of that I discovered cargo fuzz, which is a lot of fun (but if you’re curious, it doesn’t seem to be good at finding the trickiest bugs that depend on very special situations in complicated algorithm, but it finds shallower problems readily. Maybe it needs the value based coverage to handle conditionals better.)
Fuzzing with cargo fuzz
@bluss I would say that fuzzing is really, by design, forever condemned to be a poor methodology for finding bugs which depend on special input values (e.g. bad handling of zero-sized slices).
If you pick inputs randomly using a uniform distribution in a large phase space, you are very unlikely to end up on the rare input combination that causes disaster. You need to hint the algorithm in order to have reasonably good odds of falling in the right corner.
This is why I consider fuzzing as a complement to traditional testing heuristics, rather than a replacement. It is a way to explore the part of the input space where you don’t see any reason why something should go wrong, but have a quick look just in case.
Note that the fuzzer here uses feedback from the execution of the program itself, it is not just randomly feeding inputs, so it’s quite good at finding some problems.
I disagree, that sounds like a problem that’s inherent to the “naive” way of doing fuzzing, whereas nowadays tools are a lot smarter in how they decide what inputs to try. A lot of the time it’s a bit more complex than just hooking a random number generator up to your tests
That sounds a lot like American Fuzzy Lop in that it’ll inspect the machine code and use a “code coverage”-style algorithm to figure out new inputs for the fuzzing algorithm. I’d be really curious to see how it does things under the hood.
Quoting the cargo-fuzz README:
libFuzzer is going to repeatedly call the body of
fuzz_target!()with a byte buffer
With such a low-level and open-ended interface, you cannot be very smart. The best you can do is to try some basic gotchas (e.g. empty buffer slice, one-byte slice, two-byte slice), then quickly scan the search space using a simple strategy (e.g. iteratively double the buffer size) until code coverage detects a change in behaviour, then try to generate buffers of that size again and again to see if other things happen, then try to narrow down the precise buffer size where the change happens in case there’s an off-by-one lurking around… but in the end, it’s a very random and error-prone process, so finding the input that changes code coverage will always rely on a big lot of luck.
A fuzzer that would have awareness of the expected structure of the input data (e.g. a packet format specification for network protocols) could have a much smarter strategy, but that’s not what cargo-fuzz currently does.
Working on Solar Position Algorithm library, calculating sunrise/sunset at a given geo-position and Utc