l

I am running #6877 as an experiment, setting the date to `Thu, 01 Jan 1970 00:00:00 +0000`. GMX is unhappy, it returns an error: ``` host mx00.emig.gmx.net[212.227.15.9] said: 554-Transaction failed...

We should eventually enable `#![cfg_attr(not(test), forbid(clippy::indexing_slicing))]`.

I cleaned packet/many.rs as this is where panic happened in https://github.com/deltachat/deltachat-core-rust/issues/6221 due to slicing as far as I can see from backtrace.

I added errors in two places. But generally I think it does not matter much what happens in the case which must never happen as long as it does not...

Returning errors works if the function already returns `Result`, but if the function is supposed to never fail, the only options are (roughly) `unwrap()` and `unwrap_or_default()`, in which case I...

> In some such cases, I think it's also an option to change the signature to return `Result`. Although probably not in every case. We already have this in https://docs.rs/pgp/0.14.2/pgp/composed/message/enum.Message.html#method.to_armored_bytes...

> Seems to me that these fail if the underlying writer fails? `write` implementation for `Vec` never fails, it has no code path that returns errors.

> > > Seems to me that these fail if the underlying writer fails? > > > > > > `write` implementation for `Vec` never fails, it has no code...

> But the only alternative is `panic!`. The other alternative when you know some error never happens is `.unwrap_or_default()` or otherwise ignoring the error. Then if your assumption is wrong,...

Copy-pasting @adbenitez chat message regarding location permission and Google: " I am also suspecting they will come back asking to remove background location permission, which is not really needed, they...