MB
Возможно, еще безопаснее вместо ManuallyDrop будет MaybeUninit написать
Size: a a a
2020 October 22
Э
Возможно, еще безопаснее вместо ManuallyDrop будет MaybeUninit написать
Не будет, потому что всё равно трансмут из T в U.
MB
Не будет, потому что всё равно трансмут из T в U.
Я про то, что при transmute_copy с ManuallyDrop возникает ситуация, когда есть два побитово идентичных значения типа T. А это несколько подозрительно выглядит.
MB
Например для мутабельных ссылок.
Miri на это не ругается, но это не значит что так можно.
Miri на это не ругается, но это не значит что так можно.
Э
Я про то, что при transmute_copy с ManuallyDrop возникает ситуация, когда есть два побитово идентичных значения типа T. А это несколько подозрительно выглядит.
Нормально оно выглядит. Оригинальный T имеет подходящий layout, просто потому что, там что сделать memcpy на T чтобы получить ManuallyDrop<T> — норм.
Э
И ссыки там не используются.
MB
И ссыки там не используются.
Представь что T = &mut U
Э
И всё нормально.
Э
Потому что код про это не знает.
MB
Тогда у тебя лежат две независимые уникальные ссылки на один объект
Э
И если ты убиваешь первую и возвращаешь вторую, то это норма.
MB
Независимые - потому что transmute ломает provenence
Э
С тем же успехом ты можешь доказывать, что
pop на Vec<&mut T> — UB.MB
Так что это то ли нарушение алиасинга, то ли может им стать в будущем при устрожении stacked borrows.
MB
С тем же успехом ты можешь доказывать, что
pop на Vec<&mut T> — UB.Нет, там все хорошо.
MB
Динамическое хранилище нетипизировано и не обязано содержать валидное значение
MB
А стековая переменная обязана быть либо неинициализированной, либо содержать валидное значение.
Э
А стековая переменная обязана быть либо неинициализированной, либо содержать валидное значение.
Так значение валидное.
Э
Но алиаса там не будет, потому что никто не знает, что там ссылка а не указатель.
Э
Поэтому и использовать как ссылку не может.