ссылки в указатель, его в u64, его обратно в указатель, а затем указателя в ссылку UB?
А если в usize? А если не собираюсь выполняться на более чем 64-битных платформах? Или это автоматическое кладбище?
Судя по https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.addr > This is similar to self as usize, which semantically discards provenance and address-space information. However, unlike self as usize, casting the returned address back to a pointer yields invalid, which is undefined behavior to dereference. To properly restore the lost information and obtain a dereferenceable pointer, use with_addr or map_addr. Просто касты звучат незаконными. Эх.
Неоднозначно. Вообще говоря, такой каст теряет provenance указателя. Поэтому в касте обратно нужно его восстановить. Здесь и сейчас LLVM его скорее всего сможет угадать (или создаст новый, что тоже ок). Но вроде как есть баги в llvm, когда не угадывает. В расте это хотят сделать UB, но как они потом это в LLVM вставят - не очень понятно. TL;DR; пока ок, но в будущем может стать UB
Решил как время будет попробовать перепилить этот кусок на thread_local статик вектор Rc<T>, а прокидывать куда мне будет нужно буду индекс в этом векторе (может и со счётчиком чтобы запаниковать если где-то промажу таки и убежит число в будущее). Ну и в месте где лайфтайм моих ссылок бы логически закончился — подчищать его. Так хотя бы только один ансейф получается и вроде не такой страшный (а, хотя и до этого ансейф один был, но пожирнее).
И всё это потому что serde не даёт апи чтобы прокинуть в Deserialize что-нибудь от конкретной реализации десериализатора :( Что указатель на структуру приходится как u64 прокидывать. Казалось бы, что может пойти не так. О, хотя мне по сути и вектор не нужен, только статик (счётчик, значение). И в месте получения сверить счётчик, что я точно получу то значение что ожидаю, а не набаговал.
Да А если в usize/isize, то зависит от типа каста as каст примерно соответствует exposed семантике, или angelic nondet, с ним провенанс угадывается из списка уже экспоузнутых ранее максимально в сторону программиста transmute примерно соответствует non exposed семантике, или тому, что делает strict provenance, при int2ptr трансмуте указатель получит невалидный провенанс, и его использование, кроме чтения адреса, будет уб Чтобы восстановить провенанс, нужно иметь поинтер на ту же аллокацию и пользоваться анстейбл апи поинтеров Exposed не будет работать на некоторых экзотических архитектурах, такой как CHERI, там поинтеры 128 бит, а адреса всё те же 64 Ещё есть отдельный вопрос к fn поинтерам, с ними сложнее и противоречивые высказывания; на гарвардских архитектурах (wasm) их по-моему нельзя мешать с дата поинтерами, но точно сказать не могу, как правильно хранить Можно как fn(!), так безопаснее всего
deserialize_seed?
Обсуждают сегодня