Trying to understand this, if one of my students responds to my "How do we handle the reflections on trusting trust scenario" with "God will fix my compiler" and I give them bad marks, am I the bad guy
We really don't know what software we're running any more. Nor what hardware, to be honest.
That’s the beauty of open source,
there’s always someone out there, ready and willing to contribute to your project,
who is wrong.
so which conclave are they running, SGX or TrustZone?
Writing minimal reproducers for bugs is Bizarro Coding
ME WRITE CODE! OH NO CODE AM NOT BREAK? ME FIX CODE SO IT WORK WRONG!
Fixed it! Part of me thinks I should try to make a minimal reproducer, just because.. wow, that was a weird one.
OTOH I don't know if there's a lesson here other than "my code was stupid and ugly, and x86_64 & arm64 have slightly different memory ordering". I already know these things!
ya boy's first attempt at a Real Multi-threaded Rust Program turns out to have a deadlock that *only* manifests on x86_64! Ha ha ha hoo boy
i bet it feels really good to overflow if you're a buffer. they just can't get enough of it
no harm done! was a fun adventure!
buffers just love overflowing so dang much
ah shit I forgot there's no money in fixing problems!!
YEEHAW MISSION ACCOMPLISHED, I'M TECHNICALLY ALMOST A RUST CONTRIBUTOR
TIME TO BECOME CRAB BABYYYYY 🦀🦀🦀
Aaaand fixing the suspicious code in Buffer::read_more() fixes the crash. Success!!
Here's the PR to get the fix upstream: github.com/rust-lang/ru...
Changed it to peek(5) after the read(4) - which should trigger a read_more() while there's still data in the buffer - and blammo:
---- library/std/src/io/buffered/bufreader.rs - io::buffered::bufreader::BufReader<R>::peek (line 117) stdout ----
Test executable failed (signal: 6 (SIGABRT)).
6. read_to_string(s) - reads everything left ("hello") into s. Reader is now at EOF.
7. peek(1) - calls read_more(), but reader is at EOF, so it returns 0 and returns an empty buffer.
So the test does call read_more().. but it never actually reads anything! So let's fix that!
What the doctest does:
1. Make a Reader (`bytes`) containing 9 bytes: "oh, hello"
2. Wrap it in a BufReader (`buf`) with a 6-byte capacity
3. peek(2) - this causes a buffer fill. buf contains "oh, he". 4. read 4 bytes: "oh, ". buf now contains "he".
5. peek(2) - just returns "he". (cont'd..)
A screenshot of the source and doc comment for BufReader's peek function, for people who can't be bothered to follow the link to the code
Anyway! `/x.py test library/std` takes a while but all the tests pass. Great work Rust folks, high-fives all around, &c.
Now let's see if I can trigger the problem. Let's look at BufReader::peek() and its doctest: github.com/rust-lang/ru...
Have I mentioned that my internet connection is a point-to-point microwave wireless link that we share with our neighbor 'cuz our house doesn't have line-of-sight to the tower?
SORRY ABOUT YOUR NETFLIX STREAMING QUALITY BUT I GOTTA REINSTALL XCODE BECAUSE NOBODY KNOWS HOW TO FIX CONFIG FILES
apparently the only suggestion for this is.. delete & reinstall the xcode commandline utils?
sudo rm -rf $(xcode-select -p) && xcode-select --install
[redownloads 2GB of data I already had]
...aaaaand now it works! What a cool and efficient way to fix my tooling configuration!!
Okay fine whatever, setup complete, let's see if we can build the libraries! And.. uh.. hm.
fatal error: 'iostream' file not found
hoorayyyyyyy missing search paths, my favorite
So first I guess I'll clone the rust-lang/rust repo. Yeehaw, 670MG of data, let's go!
Next they suggest using their `x.py` tool to bootstrap the build environment.
Is this gonna download a buncha binary tarballs from rust-lang.org without checking sigs or certs? HELL YEAH, I LOVE SOFTWARE
First, the bug: I think there's a logic error in std::io::buffered::Buffer::read_more() that will make std::io::BufReader::peek() segfault if it has to refill the buffer.
I'm not using peek() - or nightly, for that matter - but I *did* steal Buffer::read_more() for my own thingy.
Think I just found a small bug in (unstable) Rust stdlib, yay, fun. Let's see if I can a) confirm it and b) fix it!
Periodic reminder: (()) is not a palindrome, but ())( is