Справедливости ради, если я правильно понял, здесь она предлагается не как "задача на методы строки", а как "если ты джун, а не жулик, ты за минуту напишешь цикл for и начнёшь руками перебирать символы".
На том, что большинство взрослых людей в принципе не различает понятия "не могу" и "не хочу". А как минимум одно из них там присутствовало почти наверняка.
Вообще, звучит как интересная тема не столько в плане проверки навыков (хотя и это тоже), сколько в плане проверки мотивации - не будет ли человек работать "на отвяжись, лишь бы платили". По крайней мере, вот это -
когда я в 13 почувствовал, что могу решить ЛЮБУЮ задачу (и притом довольно скудными средствами), это было сравнимо с ощущением «Я властелин мира!»
- мне очень даже знакомо, и ощущение "как мощны мои лапищи" до сих пор не проходит, даже несмотря на то, что иногда ради него приходится продираться через потроха очередного Spring. И, подозреваю, на ход работы такое отношение к процессу программирования влияет скорее положительно, чем нет.
Насколько действительно коррелируют такие задания с подобным ощущением, впрочем, судить не берусь, у меня пока что только собственный опыт, и он, честно говоря, довольно специфический.
И проблема возникнет только если заключать в unsafe большие куски кода, чтобы включить в них еще и разыменование, которое (как вы сами указали) где-то есть.
Не улавливаю мысль, честно говоря. &mut foo as *mut _можно сделать без unsafe. И оно может сломать разыменование указателя где-то дальше по курсу - пример в моём предыдущем комментарии.
В компиляторе и языке нет никаких неактивных указателей, и компилятор не проверяет правила алиасинга для указателей. Так что неактивные указатели это концепция только Miri, а мы до того обсуждали язык и компилятор.
То есть Miri, по вашему утверждению, объявляет UB то, что с точки зрения абстрактной машины Rust и оптимизаций компилятора ей не является (и не из-за того, что в спорном случае предпочитает выдать ошибку, а из-за того, что у него просто другая семантика)? Вот тут, честно говоря, хотелось бы подтверждение - по идее, если бы это было так, он был бы де-факто бесполезен, поскольку банально выдавал бы слишком много шума.
Если Rust дает возможность работать безопасно с не выровненными полями без unsafe, то зачем же я буду усложнять себе жизнь?
Если есть возможность что-то сделать без unsafe - естественно, лучше без unsafe. Повторюсь, я изначально всё это писал в предположении, что мы unsafe уже по какой-то причине используем.
Видел, и достаточно. restrict был добавлен не случайно, но при рефакторинге его гарантии случайно поломал другой программист.
Справедливо, такой вариант развития событий я не учёл. Тогда да, признаю, мой изначальный аргумент отбит.
Ну то что нужен unsafe вы совершенно случайно забыли В Rust небезопасные функции требуют unsafe
Я весь разговор вёл в контексте именно unsafe Rust - напомню изначальную цитату:
что в "unsafe rust" больше шансов поймать UB чем в Си
(выделение моё). Понятно, что в безопасном Rust всех таких проблем нет - ради этого, что называется, вся песня и писалась. Впрочем, в первом случае аргумент не совсем верен - создание указателя не unsafe, unsafe только разыменование (что, само собой, не отменяет факта, что где-то в некорректном коде unsafe действительно есть).
Интересно, что это за неактивный указатель? И кем он помечен?
Правилами алиасинга, вестимо. По крайней мере, вот на такой код Miri ругается:
fn main() {
let mut val = 42;
let ptr = &raw mut val;
&mut val;
unsafe { ptr.write(0); }
}
...причём явно указывая, что причина - " was later invalidated ... by a Unique retag" с указанием на &mut val.
Очевидно что ссылку вы не открывали. Иначе бы убедились, что в Rust в этом случае ошибка компиляции.
Открывал, почему же. Для ссылок это - ошибка компиляции. Для указателей - нет, а делать по ним ptr.read или *ptr вместо ptr.read_unaligned - это всё так же UB.
В С это доступно через restrict.
Да, я в курсе, я упомянул об этом в первом комментарии. И много вы видели ситуаций со случайно добавленным restrict? А случайно создать ссылку, ломающую работу с указателями, и не понять этого, пока не получишь замечание от Miri, - первый попавшийся пример - https://github.com/rust-lang/rust/issues/128803.
В Rust случайно создать &mut T из *mut T никак не выйдет.
Я про создание из самого T. Грубо говоря, сделать &mut foo as *mut _ вместо &raw mut foo.
Кроме того для UB нужно создать два&mut T!
Для UB нужно:
Создать ptr: *mut T.
Создать borrow: &mut T.
Использовать ptr, который при создании borrow был помечен как неактивный.
Второй &mut T здесь не нужен, достаточно будет и ptr.write.
Как насчет невыровненных ссылок?
Мы же говорим про unsafe Rust, верно? Указатель на невыровненное поле тоже должен использоваться правильно (через read_unaligned), иначе это UB.
Ну и самое типичное - выходы за пределы массива.
Мы же говорим про unsafe Rust [2]? Всякого рода get_unchecked - собственно, потому и unchecked.
Я это всё не к тому, что в Rust что-то не так (я сам его очень люблю). Просто то, что в нём есть свои способы выстрелить в ногу неопределённым поведением, которых не было в языках-предшественниках, и попытка писать на unsafe Rust как на "ещё одном Си", скорее всего, в один из них упрётся, - факт, который, AFAIK, признают и разработчики языка в том числе.
Именно доказать - нет, потому что некоторые UB из Си в Rust не переехали (знаковое переполнение, например), но новые подводные камни там действительно есть. Банально - в Си нет аналога ситуации "случайно создал &mut T при существующем *mut T, хотя хотел второй *mut T". Есть restrict, но воспользоваться им случайно, как мне кажется, весьма затруднительно.
Так бюджетники и пенсионеры указанных областей получают же выплаты в рублях.
Судя по информации с места событий - не получают. В смысле, вообще. Обанкротились области. Возможно, я что-то не так понял, конечно, сужу, как уже сказал, только по словам обитателей.
Я немного о другом. Пользуясь этой метафорой, два сценария:
Собака ничего сделать не может, но хозяин уверен, что может, и не принимает других мер.
Собака так же ничего сделать не может, но хозяин это знает и потому держит под рукой ружьё.
В каком случае безопасность лучше?
а вы рассказываете что собаки плохие, это вообще ужасный охранник, давайте лучше дом не защищать.
Если собака может защищать - естественно, лучше, когда она есть. Ключевое слово "если". А ваше сообщение выше выглядело так, как будто её наличие безусловно лучше.
И даже если бы этот рейтинг был бы куплен/продан, то это все равно лучше чем ничего
Справедливости ради, вот это совсем не факт. Тут как с системами безопасности: когда кажется, что они работают, но на самом деле не работают - это хуже, чем когда они очевидно не работают.
Получается, не существует программистов, которые думают, что ChatGPT кодит немножко лучше или хуже их? Или примерно как они сами?
Видимо, посыл в переводе с "русского вежливого" на "русский честный" звучал бы как "все программисты делятся на умных и глупых: глупые думают, что LLM может закодить лучше них - и они правы, потому что лучше них закодит даже LLM; умные знают, что не может - и они опять-таки правы". Не могу сказать, что я с такой постановкой согласен (промежуточные состояния действительно должны быть), впрочем.
У уважаемого писателя несколько альтернативная логика (ему можно, он же всё-таки фантаст), поэтому если ему что-то видится очевидным и прозрачным аки слеза младенца, то из этого совершенно не следует, что остальное человечество обязано искаропки разделять это его видение
Справедливости ради, по моему опыту, род деятельности тут ни при чём. "Очевидное" (кроме естественнонаучных аксиом, само собой) почти всегда очевидно только узкому кругу людей, независимо от вида этого "круга".
Справедливости ради, если я правильно понял, здесь она предлагается не как "задача на методы строки", а как "если ты джун, а не жулик, ты за минуту напишешь цикл for и начнёшь руками перебирать символы".
Но ещё больше проигрывает тому, кто быстро печатает, думая головой, не так ли?
На том, что большинство взрослых людей в принципе не различает понятия "не могу" и "не хочу". А как минимум одно из них там присутствовало почти наверняка.
А не /herach?
Вообще, звучит как интересная тема не столько в плане проверки навыков (хотя и это тоже), сколько в плане проверки мотивации - не будет ли человек работать "на отвяжись, лишь бы платили". По крайней мере, вот это -
- мне очень даже знакомо, и ощущение "как мощны мои лапищи" до сих пор не проходит, даже несмотря на то, что иногда ради него приходится продираться через потроха очередного Spring. И, подозреваю, на ход работы такое отношение к процессу программирования влияет скорее положительно, чем нет.
Насколько действительно коррелируют такие задания с подобным ощущением, впрочем, судить не берусь, у меня пока что только собственный опыт, и он, честно говоря, довольно специфический.
Вот это "отсылка понятна" не универсально даже для носителей русского литературного языка (как, собственно, и все языковые "очевидности").
А начинается всё с чего? Правильно - с квадратных уравнений в восьмом (или в каком там сейчас) классе, с их дискриминантами!
Уже.
А Adobe Reader так и вообще нежелательная личность?
Не улавливаю мысль, честно говоря.
&mut foo as *mut _можно сделать без unsafe. И оно может сломать разыменование указателя где-то дальше по курсу - пример в моём предыдущем комментарии.То есть Miri, по вашему утверждению, объявляет UB то, что с точки зрения абстрактной машины Rust и оптимизаций компилятора ей не является (и не из-за того, что в спорном случае предпочитает выдать ошибку, а из-за того, что у него просто другая семантика)? Вот тут, честно говоря, хотелось бы подтверждение - по идее, если бы это было так, он был бы де-факто бесполезен, поскольку банально выдавал бы слишком много шума.
Если есть возможность что-то сделать без unsafe - естественно, лучше без unsafe. Повторюсь, я изначально всё это писал в предположении, что мы unsafe уже по какой-то причине используем.
Справедливо, такой вариант развития событий я не учёл. Тогда да, признаю, мой изначальный аргумент отбит.
Я весь разговор вёл в контексте именно unsafe Rust - напомню изначальную цитату:
(выделение моё). Понятно, что в безопасном Rust всех таких проблем нет - ради этого, что называется, вся песня и писалась. Впрочем, в первом случае аргумент не совсем верен - создание указателя не unsafe, unsafe только разыменование (что, само собой, не отменяет факта, что где-то в некорректном коде unsafe действительно есть).
Правилами алиасинга, вестимо. По крайней мере, вот на такой код Miri ругается:
...причём явно указывая, что причина - " was later invalidated ... by a Unique retag" с указанием на
&mut val.Открывал, почему же. Для ссылок это - ошибка компиляции. Для указателей - нет, а делать по ним
ptr.readили*ptrвместоptr.read_unaligned- это всё так же UB.Да, я в курсе, я упомянул об этом в первом комментарии. И много вы видели ситуаций со случайно добавленным restrict? А случайно создать ссылку, ломающую работу с указателями, и не понять этого, пока не получишь замечание от Miri, - первый попавшийся пример - https://github.com/rust-lang/rust/issues/128803.
Я про создание из самого
T. Грубо говоря, сделать&mut foo as *mut _вместо&raw mut foo.Для UB нужно:
Создать
ptr: *mut T.Создать
borrow: &mut T.Использовать
ptr, который при созданииborrowбыл помечен как неактивный.Второй
&mut Tздесь не нужен, достаточно будет иptr.write.Мы же говорим про unsafe Rust, верно? Указатель на невыровненное поле тоже должен использоваться правильно (через read_unaligned), иначе это UB.
Мы же говорим про unsafe Rust [2]? Всякого рода
get_unchecked- собственно, потому и unchecked.Я это всё не к тому, что в Rust что-то не так (я сам его очень люблю). Просто то, что в нём есть свои способы выстрелить в ногу неопределённым поведением, которых не было в языках-предшественниках, и попытка писать на unsafe Rust как на "ещё одном Си", скорее всего, в один из них упрётся, - факт, который, AFAIK, признают и разработчики языка в том числе.
Именно доказать - нет, потому что некоторые UB из Си в Rust не переехали (знаковое переполнение, например), но новые подводные камни там действительно есть. Банально - в Си нет аналога ситуации "случайно создал
&mut Tпри существующем*mut T, хотя хотел второй*mut T". Есть restrict, но воспользоваться им случайно, как мне кажется, весьма затруднительно.Судя по информации с места событий - не получают. В смысле, вообще. Обанкротились области. Возможно, я что-то не так понял, конечно, сужу, как уже сказал, только по словам обитателей.
Это такой намёк, что в Тюменской и Кемеровской областях за ближайший месяц все бюджетники и пенсионеры закончатся?
Я немного о другом. Пользуясь этой метафорой, два сценария:
Собака ничего сделать не может, но хозяин уверен, что может, и не принимает других мер.
Собака так же ничего сделать не может, но хозяин это знает и потому держит под рукой ружьё.
В каком случае безопасность лучше?
Если собака может защищать - естественно, лучше, когда она есть. Ключевое слово "если". А ваше сообщение выше выглядело так, как будто её наличие безусловно лучше.
Справедливости ради, вот это совсем не факт. Тут как с системами безопасности: когда кажется, что они работают, но на самом деле не работают - это хуже, чем когда они очевидно не работают.
Видимо, посыл в переводе с "русского вежливого" на "русский честный" звучал бы как "все программисты делятся на умных и глупых: глупые думают, что LLM может закодить лучше них - и они правы, потому что лучше них закодит даже LLM; умные знают, что не может - и они опять-таки правы". Не могу сказать, что я с такой постановкой согласен (промежуточные состояния действительно должны быть), впрочем.
Ну, допустим, грабить она пропагандирует самим своим наличием. Или что, агрессивная рекламная компания - не грабёж?
(sarcasm)
Справедливости ради, по моему опыту, род деятельности тут ни при чём. "Очевидное" (кроме естественнонаучных аксиом, само собой) почти всегда очевидно только узкому кругу людей, независимо от вида этого "круга".