I'm trying to implement a simple parser for a byte stream.
I'm having troubles when I want to reuse a variable I declared previously,
fn read_data(asn_data: &mut Cursor<&[u8]>) -> Result<(u8, u8, Vec<u8>), Err> {
let total_len = asn_data.get_ref().len();
if total_len < 2 {
return Err(1);
}
let d_type = asn_data.read_u8().unwrap();
let d_len = asn_data.read_u8().unwrap();
if (asn_data.position() + d_len as u64) > total_len as u64 {
return Err(2);
}
let mut buf = vec![0; d_len as usize];
match asn_data.read_exact(&mut buf) {
Err(e) => Err(e),
Ok(()) => Ok((d_type, d_len, buf)),
}
}
fn parse_request(request: &[u8]) -> Option<u8> {
if request.len() == 0 {
return None;
}
let mut rdr = Cursor::new(request);
let data_tuple = read_data(&mut rdr).unwrap();
println!("{:02?}", data_tuple.2);
rdr = Cursor::new(data_tuple.2.as_slice());
let data_tuple = read_data(&mut rdr).unwrap();
println!("{:02x?}", data_tuple.2);
Some(1)
}
In the parse_request function I want to reuse rdr variable, but with the code shown above I get the next error when compiling:
error[E0597]: data_tuple.2 does not live long enough -->
src/main.rs:80:23
| 80 | rdr = Cursor::new(data_tuple.2.as_slice());
| ^^^^^^^^^^^^ borrowed value does not live long enough ... 104 | }
| - data_tuple.2 dropped here while still borrowed
|
= note: values in a scope are dropped in the opposite order they are created
error: aborting due to previous error
However if I write "let mut" when I use the 2nd time rdr variable, the code compiles and works fine...
let mut rdr = Cursor::new(data_tuple.2.as_slice());
I don't understand why... what I want is to reuse the variable instead to declare it again...
I tried with some examples/issues related to variable life time but I didn't get the solution for my case... and the solution I found I don't understand fully...
This is not connected with tuple lifetimes, this is just the drop order.
When the variables are defined in separate let statements in the same scope (that is, in the same block), they will be dropped in reverse order. Looking at your code, we can see:
let mut rdr = Cursor::new(request);
let data_tuple = read_data(&mut rdr).unwrap();
So, data_tuple will be dropped first, while rdr is still alive. This is bad, because rdr must reference the tuple. The easiest fix will be to swap their definitions:
let data_tuple: (u8, u8, Vec<u8>);
let mut rdr = Cursor::new(request);
data_tuple = read_data(&mut rdr).unwrap();
This way, rdr will be dropped first, releasing the reference to data_tuple and letting the tuple be dropped itself.
The "fix" you mentioned works, because every let statement defines new variable, even if the same name is already used, and the existing variable is immediately forgotten. So, when you write:
let mut rdr = Cursor::new(request);
let data_tuple = read_data(&mut rdr).unwrap();
let mut rdr = Cursor::new(data_tuple.2.as_slice());
the second rdr is in no way connected with the first. Essentially, it's almost the same as declaring two different variables, say, rdr and rdr2, and using rdr2 from this place until the end of function.
Related
I have the following code:
use std::collections::HashMap;
fn doublez(h1: &HashMap<String, i32>, h2: &HashMap<String, i32>) {
dbg!(h1, h2);
}
fn main() {
let mut scores = HashMap::new();
scores.insert(String::from("Blue"), 10);
scores.insert(String::from("Yellow"), 50);
let teams = vec![
String::from("Blue"),
String::from("Yellow"),
];
let initial_scores = vec![10, 50];
let team_scores: HashMap<_, _> = teams.into_iter().zip(initial_scores.into_iter()).collect();
let mut ts2 = &team_scores;
let mut ts3 = &team_scores;
doublez(ts2, ts3);
}
I'm experimenting with Rusts ownership rules and I was testing out the whole idea that you can't have multiple mutable references, but here in this code, I make two mutable references to the team_scores hashmap in the form of ts2 and ts3 but for whatever reason the code compiles just fine. Why is that?
let mut ts2 = &team_scores is not actually creating a mutable reference, but rather a mutable variable containing an immutable reference. This means you can reassign the variable to another reference (i.e. ts2 = &different_hashmap), but you won't be able to modify the HashMap itself (i.e. trying to call ts2.insert will not work).
If you want a mutable reference to the HashMap, you would use let ts2 = &mut team_scores;.
I want to get two values from a hashmap at the same time, but I can't escape the following error, I have simplified the code as follows, can anyone help me to fix this error.
#[warn(unused_variables)]
use hashbrown::HashMap;
fn do_cal(a: &[usize], b: &[usize]) -> usize {
a.iter().sum::<usize>() + b.iter().sum::<usize>()
}
fn do_check(i: usize, j:usize) -> bool {
i/2 < j - 10
}
fn do_expensive_cal(i: usize) -> Vec<usize> {
vec![i,i,i]
}
fn main() {
let size = 1000000;
let mut hash: HashMap<usize, Vec<usize>> = HashMap::new();
for i in 0..size{
if i > 0 {
hash.remove(&(i - 1));
}
if !hash.contains_key(&i){
hash.insert(i, do_expensive_cal(i));
}
let data1 = hash.get(&i).unwrap();
for j in i + 1..size {
if do_check(i, j) {
break
}
if !hash.contains_key(&j){
hash.insert(j, do_expensive_cal(j));
}
let data2 = hash.get(&j).unwrap();
let res = do_cal(data1, data2);
println!("res:{}", res);
}
}
}
Playground
error[E0502]: cannot borrow hash as mutable because it is also borrowed as immutable
--> src/main.rs:26:8
|
19 | let data1 = hash.get(&i).unwrap();
| ------------ immutable borrow occurs here
...
26 | hash.insert(j, vec![1,2,3]);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
...
29 | let res = do_cal(data1, data2);
| ----- immutable borrow later used here
For more information about this error, try rustc --explain E0502.
error: could not compile playground due to previous error
Consider this: the borrow checker doesn't know that hash.insert(j, …) will leave the data you inserted with hash.insert(i, …) alone. For the borrow checker, hash.insert(…) may do anything to any element in hash, including rewriting or removing it. So you can't be allowed to hold the reference data1 over hash.insert(j, …).
How to get over that? The easiest is probably to move let data1 = hash.get(…) so it doesn't have to live for so long:
let data1 = hash.get(&i).unwrap();
let data2 = hash.get(&j).unwrap();
let res = do_cal(data1, data2);
This will of course look up data1 every loop iteration (and it must, since hash.insert(j, …) may have resized and thus realocated the content of the hashmap, giving data1 a new storage location in the hashmap). For completeness's sake, there are ways to get around that, but I don't recommend you do any of this:
Clone: let data1 = hash.get(&i).unwrap().clone() (if your vecs are short, this may actually be reasonable…)
As a way of making the cloning cheap, you could use a HashMap<usize, Rc<Vec<usize>>> instead (where you only need to clone the Rc, no the entire Vec)
If you ever need mutable references to both arguments of do_call, you could combine the Rc with a RefCell: Rc<RefCell<Vec<…>>>
If you need to overengineer it even more, you could replace the Rcs with references obtained from allocating in a bump allocator, e.g. bumpalo.
Since the keys to the hash table are the integers 0..100 you can use a Vec to perform these steps, temporarily splitting the Vec into 2 slices to allow the mutation on one side. If you need a HashMap for later computations, you can then create a HashMap from the Vec.
The following code compiles but panics because the j - 10 calculation underflows:
fn do_cal(a: &[usize], b: &[usize]) -> usize {
a.iter().sum::<usize>() + b.iter().sum::<usize>()
}
fn do_check(i: usize, j:usize) -> bool {
i/2 < j - 10
}
fn main() {
let size = 100;
let mut v: Vec<Option<Vec<usize>>> = vec![None; size];
for i in 0..size {
let (v1, v2) = v.split_at_mut(i + 1);
if v1[i].is_none() {
v1[i] = Some(vec![1,2,3]);
}
let data1 = v1[i].as_ref().unwrap();
for (j, item) in (i + 1..).zip(v2.iter_mut()) {
if do_check(i, j) {
break
}
if item.is_none() {
*item = Some(vec![1,2,3]);
}
let data2 = item.as_ref().unwrap();
let res = do_cal(data1, data2);
println!("res:{}", res);
}
}
}
I'm new to Rust and still reading the Rust book. Below is my program.
use clap::{App, Arg};
type GenericError = Box<dyn std::error::Error + Send + Sync + 'static>;
type GenericResult<T> = Result<T, GenericError>;
fn main() -> GenericResult<()> {
let matches = App::new("test")
.arg(Arg::new("latency")
.takes_value(true))
.get_matches();
let latency_present = matches.is_present("latency");
let latency = matches.value_of("latency").unwrap_or("1000:10,300:30");
let latency_pairs: Vec<&str> = latency.split(",").collect();
let checker = std::thread::spawn(move || -> GenericResult<()>{
loop {
if latency_present {
for (i, latency_pair) in latency_pairs.iter().enumerate() {
// let latency_pair: Vec<&str> = latency_pair.split(":").collect();
// let latency = latency_pair[0].parse::<f64>().unwrap();
}
}
}
});
checker.join().unwrap()?;
Ok(())
}
When I run it, it tells me this:
error[E0597]: `matches` does not live long enough
--> src\main.rs:14:19
|
14 | let latency = matches.value_of("latency").unwrap_or("1000:10,300:30");
| ^^^^^^^--------------------
| |
| borrowed value does not live long enough
| argument requires that `matches` is borrowed for `'static`
...
30 | }
| - `matches` dropped here while still borrowed
I don't quite understand the error messages here. But I guess it's because I use latency_pairs in the checker thread and latency_pairs could get dropped while checker is still executing. Is my understanding correct? How to fix the error? I tried for (i, latency_pair) in latency_pairs.clone().iter().enumerate() { in order to pass a cloned value for the thread, but it doesn't help.
latency_pairs holds references into latency which in turn references matches. Thus cloning latency_pairs just clones the references into latency and matches.
Your code would require that latency's type is &'static str but it's actually &'a str where 'a is bound to matches' lifetime.
You can call to_owned() on latency to get an owned value and split the string inside the closure or you can call to_owned() on each of the splits collected in latency_pairs and move that Vec<String> into the closure:
let latency_pairs: Vec<String> = latency.split(",").map(ToOwned::to_owned).collect();
let checker = std::thread::spawn(move || -> GenericResult<()>{
loop {
if latency_present {
for (i, latency_pair) in latency_pairs.iter().enumerate() {
// let latency_pair: Vec<&str> = latency_pair.split(":").collect();
// let latency = latency_pair[0].parse::<f64>().unwrap();
}
}
}
});
If you need to use latency_pairs outside of the closure, you can clone it before moving it into the closure:
let latency_pairs: Vec<String> = latency.split(",").map(ToOwned::to_owned).collect();
let latency_pairs_ = latency_pairs.clone();
let checker = std::thread::spawn(move || -> GenericResult<()>{
loop {
if latency_present {
for (i, latency_pair) in latency_pairs_.iter().enumerate() {
// let latency_pair: Vec<&str> = latency_pair.split(":").collect();
// let latency = latency_pair[0].parse::<f64>().unwrap();
}
}
}
});
println!("{:?}", latency_pairs);
Consider the following code:
use std::io::{self, BufRead, Read};
fn main() {
let mut stdin = io::stdin();
let mut content_length = 0;
for line_wrapped in stdin.lock().lines() {
let line = line_wrapped.unwrap();
if line == "" {
let mut buf = vec![0u8; content_length];
stdin.read_exact(&mut buf).unwrap();
print!("{:?}", buf);
}
if line.starts_with("Content-Length: ") {
content_length = line
.split("Content-Length: ")
.nth(1)
.unwrap()
.parse()
.unwrap();
}
}
}
And the compiler output:
error[E0502]: cannot borrow `stdin` as mutable because it is also borrowed as immutable
--> src/main.rs:11:13
|
7 | for line_wrapped in stdin.lock().lines() {
| ----- immutable borrow occurs here
...
11 | stdin.read_exact(&mut buf).unwrap();
| ^^^^^ mutable borrow occurs here
...
22 | }
| - immutable borrow ends here
Is there a way I could fix the error while keeping a similar structure of the program (read within a .lines())?
Alternating between buffered and non-buffered reads of the same stream can be quite tricky. If you didn't have to lock standard input in order to call lines(), the internal buffer used to implement StdinLock could consume beyond the \n of the empty line, and the subsequent read_exact call would not start at the right place.
So you have to lock it only once, and you have to call read_exact on the same buffered reader that gave you the Lines, to be sure no bytes are lost. At first glance this looks impossible: lines() takes self by value, so once you've called it, you can't call read_exact on the same object. But there's a bit of a trick you can use.
The documentation for BufRead contains this blanket impl:
impl<'a, B: BufRead + ?Sized> BufRead for &'a mut B
&mut references to things that implement BufRead also implement BufRead. So you can take a temporary &mut reference of your StdinLock, call lines() on that, discard the Lines in time to read_exact the payload into buf, and then start over again with another &mut reference and another Lines.
This approach necessitates adding another loop, with a flag has_header to indicate whether to break the outer loop. It's not very pretty, but maybe you can work with it.
let stdin = io::stdin();
let mut stdin_buf = stdin.lock();
'record: loop {
let mut content_length = 0;
let mut has_header = false;
'header: for line_wrapped in (&mut stdin_buf).lines() {
let line = line_wrapped.unwrap();
if line.starts_with("Content-Length: ") {
content_length = line["Content-Length: ".len()..].parse().unwrap();
}
if line.is_empty() {
has_header = true;
break 'header;
}
}
if has_header {
let mut buf = vec![0u8; content_length];
stdin_buf.read_exact(&mut buf).unwrap();
println!("{:?}", buf);
} else {
break 'record;
}
}
A final note: It's unclear what should happen when the Content-Length header is absent. If your original code worked, it would reuse the previously defined value (whatever the last content length was, or 0 for the first record). My version just uses 0 all the time. It's idiomatic in Rust to use Option to represent possibly-uninitialized values such as content_length, so initializing it to None could be a better option if the absence of a Content-Length header is an error that needs to be detected.
I have a basic (and probably stupid) ownership question. I am trying to create a vector of &str from String values wrapped inside Some(String). I am using an intermediate variable to store the extracted/unwrapped String and it seems I need to define this intermediary variable before the vector in order to satisfy the borrow checker:
Working code:
fn main() {
let a = Some("a".to_string());
let mut val = String::new();
let mut v = Vec::<&str>::new();
if a.is_some() {
val = a.unwrap();
v.push(&val[..]);
}
println!("{:?}", val);
}
Non working code:
fn main() {
let a = Some("a".to_string());
let mut v = Vec::<&str>::new();
let mut val = String::new();
if a.is_some() {
val = a.unwrap();
v.push(&val[..]);
}
println!("{:?}", val);
}
And the compiler errors:
<anon>:9:17: 9:20 error: `val` does not live long enough
<anon>:9 v.push(&val[..]);
^~~
<anon>:4:35: 12:2 note: reference must be valid for the block suffix following statement 1 at 4:34...
<anon>:4 let mut v = Vec::<&str>::new();
<anon>:5 let mut val = String::new();
<anon>:6
<anon>:7 if a.is_some() {
<anon>:8 val = a.unwrap();
<anon>:9 v.push(&val[..]);
...
<anon>:5:32: 12:2 note: ...but borrowed value is only valid for the block suffix following statement 2 at 5:31
<anon>:5 let mut val = String::new();
<anon>:6
<anon>:7 if a.is_some() {
<anon>:8 val = a.unwrap();
<anon>:9 v.push(&val[..]);
<anon>:10 }
...
error: aborting due to previous error
playpen: application terminated with error code 101
The playpen code
The question is: why do I have to define the val variable before the vector v? As I see it, val scope is the same as v scope, or am I missing something?
Bindings are dropped in reverse order of declaration, i.e. the most recently declared thing is destroyed first. Specifically, in the code that doesn't work, the destructor of val runs before the destructor of v. Without careful consideration of what Vec<&str>::drop() does, this is not safe: It could for example try to look at the contents of the string slices it contains, despite the fact that the String from which they derive is already destroyed.
Vec doesn't actually do that, but other legitimate types do something along those lines. Previously it was impossible to safely implement Drop for types that contain lifetimes/borrowed pointers. A relatively recent change makes it safe by introducing these additional restrictions.
Note that if you declare let v, val; or let val, v; and later assign, the two bindings do have the same lifetime, so it's not impossible to have two variables of the same lifetime.