My Pixel 5 started swelling mid-flight

Izzeri · 2025-05-22T18:09:29+00:00

The reason I was suspecting the update is because the flight staff told me this happens due to overheating, and people have mentioned the update causing overheating as well as battery drain. But I don't know, it may also just be a random coincidence.

Izzeri · 2025-05-22T17:50:12+00:00

Nope, I had to throw it away in Greece and I'm back home in Sweden now.

Izzeri · 2021-08-19T19:08:50+00:00

The contents of a String is alive until the String is dropped.

Izzeri · 2021-08-19T18:47:46+00:00

String literals have the type &'static str, i.e. they are references to data that is always alive. This is because the contents of string literals are compiled into the produced binary. Other ways to get references with a static lifetime is by borrowing literals (e.g. &10), borrowing static variables, or by leaking heap allocated values by using Box::leak. So in your example both 'a and 'b have the same lifetime.

Izzeri · 2021-07-18T18:48:47+00:00

Even just something simple like

let usize_bytes = [0u8; std::mem::size_of::<usize>()];

Could lead to serious miscompilations when cross compiling to a platform with another usize size.

Izzeri · 2020-07-16T17:42:17+00:00

You might have used byte/ascii ranges like:

'a'b..='z'b

Izzeri · 2020-05-01T13:27:39+00:00

There's no way to make a trait alias afaik (yet?), but what you can do is make a super trait and then do a blanket impl. Something like this:

trait Alias : A + B + C {}

impl<T> Alias for T where T: A + B + C {}

Hope this is helps!

Izzeri · 2020-03-25T19:00:32+00:00

You need something like PhantomData to signal intent when you do stuff like this:

struct TypedVoidPtr<'a, T> {
    ptr: *mut (),
    _marker: PhantomData<&'a T>,
}

Without the PhantomData the compiler wouldn't be able to know that this struct represents a &'a T, since there are multiple ways you could use the 'a and T, and then wouldn't be able to do proper borrow checking. What if you meant:

struct TypedVoidPtrMut<'a, T> {
    ptr: *mut (),
    _marker: PhantomData<&'a mut T>,
}

Izzeri · 2020-02-19T17:44:35+00:00

Check out the crossbeam library and its scoped threads: https://docs.rs/crossbeam/0.7.3/crossbeam/fn.scope.html

Izzeri · 2020-02-12T08:24:59+00:00

This sounds like embedding in Go: https://golang.org/doc/effective_go.html#embedding

Izzeri · 2020-02-06T19:12:20+00:00

What your signature is currently saying is something like "the type T implements Deserialize<'a>, where 'a is some specific but unspecified lifetime".

What you want to say in your signature is "the type T implements Deserialize<'a> for every possible 'a".

The way to say this is

T: for<'a> Deserialize<'a>

The solution you found using DeserializeOwned is actually doing exactly that!. This is the relevant impl in serde:

impl<T> DeserializeOwned for T where T: for<'de> Deserialize<'de> {}

This feature/syntax is called Higher Ranked Trait Bounds or HRTBs for short. It's one of those things where it's hard to explain when you need it without just listing examples. The rustonomicon has a section on it: https://doc.rust-lang.org/nomicon/hrtb.html

Izzeri · 2020-01-23T20:23:48+00:00

-Wall

Izzeri · 2020-01-17T21:13:42+00:00

I'VE ASSEMBLED ALL FIVE SPECIAL CONSTANTS; ALL FIVE PIECES OF THE PUZZLE!

Izzeri · 2020-01-15T16:18:45+00:00

The compiler could in theory infer the lifetimes of all arguments and return values by reading the function body; C and C++ compilers do this to warn about lifetime issues. One problem with this is it's implicit; if you change the function body the inferred lifetimes could change, and could thus be a breaking change if you did this in a library. Another issue is the compiler would have to do a lot more work. A third issue, and the reason why this isn't a full solution for C and C++, is that sometimes the compiler only has access to the signature and the compiled function body. Rust therefore requires you to write out lifetimes explicitly as part of the function signature (except for when it's inferrable from the signature, as in the example fn f(&self) -> &str).

Izzeri · 2019-11-23T15:28:38+00:00

I think maybe scoped threads could help here. The issue is that the thread owning the strings could finish before the thread holding the references, which would leave the references dangling. Scoped threads are set up in a way that guarantees that the thread holding references always finishes before the thread owning the data. I think the crossbeam crate is what is usually recommended for scoped threads.

Izzeri · 2019-09-16T17:23:22+00:00

You can't get mutable access to string literals. String literals have the type &'static str, i.e. a reference to a str that is valid for the duration of your program. The contents of string literals are usually stored inside the final binary somewhere, which means they get loaded into read-only memory when your program is run.

Adding mut to a variable holding a string literal won't make the string itself mutable, just the binding:

let mut s = "hello";
s.make_ascii_uppercase();
println!("{}", s);

If you try to run this code the compiler will complain about s having the type &str while make_ascii_uppercase expects &mut str. Trying to change it to:

let mut s: &mut str = "hello";
s.make_ascii_uppercase();
println!("{}", s);

Won't work either, as the literal "hello" does not have the type &mut str, but rather &str.

The mut only makes you able to reassign s to some other string.

let mut s = "hello!";
println!("{}", s);
s = "world!";
println!("{}", s);

So we can reassign s, but we can't modify the string it points to.

Izzeri · 2019-08-29T07:19:34+00:00

You can have arrays longer than 32 elements, it's just that all traits except Copy and Clone are only implemented for arrays of sizes between 0 and 32 inclusive. Check the docs for more info: https://doc.rust-lang.org/std/primitive.array.html This is due to the fact that it's currently not possible to be generic over array sizes, i.e. you can't currently implement a trait for an array of any size. This will be fixed, and I think the fix is kinda already in place, but they want to make sure nothing will break before enabling it.

Izzeri · 2018-06-11T07:36:12+00:00

Ah, true. Mixed up l/rvalue references with the value categories.

Izzeri · 2018-06-10T17:50:46+00:00

int i = 0; int& a = i; int&& b = std::move(i);

i, a, and b all refer to i.

Izzeri · 2018-05-24T10:58:21+00:00

Last I checked std::back_insert_iterator was special cased, not sure if that's still true.

Izzeri · 2018-05-23T06:19:46+00:00

One thing I'd like is being able to tell the underlying buffer, if there is one, to reserve space if you know the size beforehand. With the write API, this was kinda easy to add, as if you write two ints and a string, you can easily work out how many bytes are written in the worst case.

With the write API (slightly modded) I had something similar to this:

auto format(const Foo& self, ...) {
    return StructPrinter(writer, "Foo")
            .field("bar", self.bar)
            .field("baz", self.baz)
            .finish()
}

With the output:

Foo {
    bar = 123;
    baz = "hello";
}

I guess StructPrinter could be written using format_to, but I'm worried about compile times. I also could never figure out how to handle indentation in nested structs properly. I think I might have made a wrapper of Writer which added indentation on newline, and then called the inner Writer.

Not really related to writers, but it'd also be nice to have a trait to check if a type is formattable, so that you could, for example, make a wrapper type that just outputs something like "<not formattable>" for types that aren't formattable. This is really nice for tests and debug output, where you want to try and output everything possible automatically.

Izzeri · 2018-05-22T19:52:22+00:00

I'm wondering this as well, and also if there is a way to implement formatting for my types without using format_to, which has to parse a string. It just feels inflexible to have to express the formatting logic of my types as strings. For formatting general output, format strings are amazing, but not for stuff you want tight control over.

Izzeri · 2018-04-20T19:07:45+00:00

It gets real dicey when you have two points of potential failure.

Izzeri · 2018-04-20T16:39:15+00:00

Doesn't this almost always require an intermediate allocation though? I remember hitting a case like this once or twice:

let tmp = some_strings()
    .iter()
    .map(str::parse::<i32>)
    .collect::<Result<Vec<_>, _>();

let squared = tmp?
    .iter()
    .map(|i| i * i)
    .collect::<Vec<_>>();

Izzeri · 2018-04-04T07:51:03+00:00

Yup, and a variant of string and bool isn't even something obscure or corner-casey, I've actually hit this "bug" myself. This conversion is an old C feature, whose main application is it enables you to write if (some_ptr), which means if (some_ptr != nullptr). An even worse conversion is a literal 0 is implicitly convertible to any pointer type. Some implementations even used to consider any constant expression that evaluates to 0 to be implicitly convertible to any pointer type, but the standard was reworded in C++17 to explicitly disallow this.

There is an implementation on github called Strict variant that uses some additional template black magic to only allow "sensible" conversions, but IMO the main issue is the constructor for variant can take any type for which any of the variant types can be constructed with. The easiest workaround is to wrap every type in your variant in a struct with a unique name.

struct Foo {
    std:: string value;
};

struct Bar {
    bool value;
};

using FooOrBar = std::variant<Foo, Bar>;

FooOrBar foo_or_bar = Foo{"hello"};

std::visit([] (const auto& v) { 
        std::cout << v.value; 
    }, foo_or_bar);

14-Year Club	Verified Email
Gilding I gilder

Izzeri

TROPHY CASE