С++ имеет синтаксис для некорректных функций

Если используете либы с unsafe - то может и надо.

Чувак, в std есть unsafe.

Можно проверить, используют ли они unsafe.

Если без nostd — сто пудов используют :))

Выборка ни о чём.

Ну пребывай в плену иллюзий.

действительно. чего это жабокреки вылезли из своей песочницы? а ну, геть обратно в загон!

не умеешь - не лезь. ни С, ни плюсы не обязаны защищать вас от собственной дурости. в них разрешено стрелять себе в ногу. выбор за самим программистом. это защищает сишные языки от неосиляторов: они самовыпиливаются.

Те же яйца, только в профиль.

Это защищает сишные языки от нормальных библиотек.

Я читал это. Прекрасная причина избегать либ на unsafe Rust, вроде treebitmap.

В стандартной растовой библиотеке есть unsafe код. Предлагаешь работать с nostd?

Предлагаю не прикидываться шлангом и не паясничать.

А ты назовешь вторую либу, в которой ловишь сегфолты? И третью, и далее.

Понятия не имею, что там ещё сегфолтится

Ясно.

ты намекаешь на безудержную крутость явы

Нет. Я намекаю, чтобы ты пользовался инструментом который ты хоть как-то знаешь.

не умеешь - не лезь. ни С, ни плюсы не обязаны защищать вас от собственной дурости

Так ведь никто не умеет. И ты тоже не умеешь.

а ничего, что функция может возвращать не только ретурном, но исключениями сыпать, например?

а ничего, что иногда функциям необходим стандартизированную сигнатуру, например, если это виртуальные функции разных классов, но при этом часть функций могут реально значение и не возвращать, по причине, хотя бы, указанной выше ?

или ей нужно возвращать значение, чтобы поместиться в шаблон?

Стиви, пиши на Яве. Пожалуйста.

Неть, ну как же мы еще узнаем, от чего у него банбит, когда у него опять много свободного времени?

Чувак, в std есть unsafe.

Вы открыли мне глаза!

Проблема в том, что вы не понимаете и не хотите понять какие гарантии даёт Rust. Никакой серебряной пулей его никто не считает.

даже 17

Ах, да, начиная с 11 есть [[ noreturn ]]

:)

Проблема в том, что вы не понимаете и не хотите понять какие гарантии даёт Rust.

Прекрасно понимаю. А еще я понимаю, что отмазка «это не мой код, это чужая библиотека упала!» работает только один раз, и то пока ты джун.

Никакой серебряной пулей его никто не считает.

А вот в этом я почему-то сомневаюсь.

и чём «нормальность» в твоей странной интерпретации?

так-то на си написаны, наверное, миллионы нормальных библиотек. ну, в понимании нормального программиста, а не неосилятора, который любит стрелять себе в ногу.

и чём «нормальность» в твоей странной интерпретации?

Хочу хорошо отлаженную, типобезопасную (как в sys/queue.h) роутинговую таблицу по типу ART. Нет, я знаю, что могу вытащить кишки из OpenBSD или там лялеха какого-нибудь, но я хочу готовое. И чтобы протестировано было.

я-то умею. я же не жалуюсь на С. кстати, писать на С я начала ещё в школьные годы. и уже тогда он не вызывал никаких вопросов. хотя не было никаких интернетов и форумов. был только K&R и текстовый файлик с кратким описанием стандартных функций libc. это к вопросу об уровне развития тех, кто плачет тут про неосиляторство. просто некоторым гражданам не надо вообще программированием заниматься, очевидно.

Баг в конкретной либе vs. баг дизайна языка. Что же хуже? (сарказм)

Баг в конкретной либе vs. баг дизайна языка. Что же хуже? (сарказм)

Какая разница с точки зрения QA? Тестировать придется в любом случае, причем в одинаковом объеме.

отмазка «это не мой код, это чужая библиотека упала!» работает только один раз, и то пока ты джун.

Когда ты решил использовать насыщенную unsafe библиотеку версии 0.3.1, последний коммит в которой был полгода назад, ты не должен жаловаться на сегфолты.

Какая разница с точки зрения QA?

Я надеюсь это шутка.

никому кроме тебя такой монстр не нужен. если хочешь - сам и напиши.

Когда ты решил использовать насыщенную unsafe библиотеку версии 0.3.1, последний коммит в которой был полгода назад, ты не должен жаловаться на сегфолты.

Мы тут о разных вещах говорим, мне так кажется. Я говорю о том, что язык не является панацеей, и тестировать тебе один хрен придется. Так что с точки зрения QA, если Rust и уменьшает количество работы, то не то чтобы на порядок.

я-то умею

Нет.

я же не жалуюсь на С

Жалобы по крайней мере показывают, что ты недоволен инструментом, и могут показывать, что ты понимаешь его недостатки.

никому кроме тебя такой монстр не нужен. если хочешь - сам и напиши.

Ээээ... Сейчас это считается одной из самых сбалансированных роутинговых таблиц для generic purpose. У тебя есть идеи получше?

Я надеюсь это шутка.

Отнюдь. Если ты мне не покажешь, какие же такие тесты в природе ловят ТОЛЬКО ошибки памяти.

Ну вот в динамически типизированных языках нужно писать тесты для проверки работы функций, которым передают всякий мусор. В статически типизированных - не нужно. «С точки зрения QA» нужно это тестировать? Я думаю нет.

Тоже самое с растом. Напороться на сегфолт в расте - это нужно постараться. А в C/C++ это обычное дело.

Не распарсил.

Тоже самое с растом. Напороться на сегфолт в расте - это нужно постараться. А в C/C++ это обычное дело.

Ты мне можешь привести пример теста (юнит или интеграционного), который тестирует ТОЛЬКО возможность сегфолта? Фаззер не предлагать, он ловит в том числе ошибки логики и нужен в любом случае.

Не распарсил.

Я не могу сходу представить тест, который ловит ошибки памяти, но при этом не ловит какие-то другие ошибки.

Зачем мне тестировать сегфолт, которого не может быть?

Разверните мысль.

Зачем мне тестировать сегфолт, которого не может быть?

Ты не можешь быть так уверен, пока std rust'а не избавится от unsafe кода и биндингов к libc.

Разверните мысль.

Я хочу увидеть тест, который тестирует код на сегфолт, но не тестирует на ошибки логики. Потому что если тест на ошибки логики все равно придется писать, то я не понимаю, как Rust сокращает время на QA.

Я говорю о том, что язык не является панацеей, и тестировать тебе один хрен придется.

А кто считает язык панацеей? Ты придумал что-то и разоблачаешь это с пылом молодого правдоруба. Просто для протокола: safe Rust гарантирует memory safety _при отсутствии_ ошибок в примитивах, использующих в своей реализации реализации usafe.

Так что с точки зрения QA, если Rust и уменьшает количество работы, то не то чтобы на порядок.

А меньше чем на порядок ты не согласен? Старые лекции по SE говорят, что менять инструмент выгодно уже тогда, когда выигрыш составляет 37%.

А кто считает язык панацеей? Ты придумал что-то и разоблачаешь это с пылом молодого правдоруба. Просто для протокола: safe Rust гарантирует memory safety _при отсутствии_ ошибок в примитивах, использующих в своей реализации реализации usafe.

Иди троллируй в другое место, а?

если тест на ошибки логики все равно придется писать, то я не понимаю, как Rust сокращает время на QA.

Ты только думаешь, что не понимаеь это, а не понимаешь другую вещь.

Ты не можешь быть так уверен, пока std rust'а не избавится от unsafe кода и биндингов к libc.

Заодно и от llvm и всех багов компилятора. Говорю же, Вы не понимаете гарантий, которые вам предлагают.

Я хочу увидеть тест, который тестирует код на сегфолт, но не тестирует на ошибки логики.

Кто сказал, что ошибка логики должна приводить к сегфолту? Повторюсь: ошибка в коде != ошибка в дизайне языка. В C я должен написать тест, который проверит, что передавая в функцию NULL - она отработает верно. В Rust вообще нет NULL, соответственно и тест такой не нужен. А значит и работы меньше.

Ты только думаешь, что не понимаеь это, а не понимаешь другую вещь.

Я всегда удивлялся твоей неспособности писать законченные мысли.

Ты только думаешь, что не понимаеь это, а не понимаешь другую вещь.

Я всегда удивлялся твоей неспособности писать законченные мысли.

Это оставлено как упражнение для читателя.

Заодно и от llvm и всех багов компилятора. Говорю же, Вы не понимаете гарантий, которые вам предлагают.

Мы опять о разных вещах говорим. Ты говоришь, что в safe Rust проблем с порченной памятью быть не должно. И, ВНЕЗАПНО, я с этим не спорю. Но при написании реального приложения для решения каких-то реальных задач, нам нужно учитывать баги сторонних библиотек, баги libc, llvm и компилятора. Потому что заказчику абсолютно плевать, почему ты потерял его данные.

Кто сказал, что ошибка логики должна приводить к сегфолту? Повторюсь: ошибка в коде != ошибка в дизайне языка. В C я должен написать тест, который проверит, что передавая в функцию NULL - она отработает верно.

Вообще нет. В идеале ты пишешь тест, который прогоняет функцию через все множество допустимых значений. И тут уж одним больше, одним меньше — пофиг. К тому же, функции крайне редко должны переживать принимаемый NULL.

В Rust вообще нет NULL, соответственно и тест такой не нужен. А значит и работы меньше.

Ну если ты проверяешь только NULL, то, наверное, меньше. Но я таких тестов как-то не особо видел. Разве что для free().

Это оставлено как упражнение для читателя.

Иди троллируй в другое место. Здесь еды нет.

Иди троллируй в другое место.

Кот бы говорил.

И таки попробуй понять, чем различаются проверки компиляции/времени исполнения и тесты.

Ты говоришь, что в safe Rust проблем быть не может.

Я такого не говорил. Я сказал, что очень маловероятно. В чём и суть раста - вероятность ошибки.

И тут уж одним больше, одним меньше — пофиг.

Ох лол. 0 тестов vs 1 тест * количество функций принимающих NULL.

Ну если ты проверяешь только NULL, то, наверное, меньше.

Нут так -1 тут, -1 там - вот и набрали прилично.

Но я таких тестов как-то не особо видел.

А вот и субъективщина пошла.

А вот и субъективщина пошла.

Нет, пошла конкретика, которой ты почему-то не можешь предоставить. Ты мне говоришь, что в C зачем-то нужно писать тесты на NULL pointer. Но зачем? Насколько часто ты делаешь NULL валидным значением? Как сильно отличается тест для пары valid_ptr/NULL от Option?

Если ты не понял, то я плавно подвожу к тому, что если у тебя NULL выступает в качестве замены для Option, то тест все равно нужен, потому что тебе нужно проверить логику работы функции при двух разных значениях.

Нет, пошла конкретика, которой ты почему-то не можешь предоставить.

Конкретика основанная на личном опыте? Ну ок.

Ты мне говоришь, что в C зачем-то нужно писать тесты на NULL pointer. Но зачем?

Хороший вопрос. Нет.

Как сильно отличается тест для пары valid_ptr/NULL от Option?

Как минимум тем, что второй не может привести к сегфолту. Соответственно -1 головная боль.

Как минимум тем, что второй не может привести к сегфолту. Соответственно -1 головная боль.

Не торопись. Поскольку C лишен нормальной системы типов, то NULL часто используется для замены Option.

То есть у нас есть два типа функций: для одних NULL является индикатором отсутствия значения (суррогат Option), для других NULL является просто ещё одним валидным значением. И если первых я могу понапридумывать сколько угодно, то вторых на память приходит довольно мало (тот же free).

А теперь расскажи мне, почему пару ptr/NULL проверять нужно, а Option — нет, хотя логические ошибки могут быть в обоих случаях.

почему пару ptr/NULL проверять нужно, а Option — нет, хотя логические ошибки могут быть в обоих случаях.

Потому что указатель можно использовать неправильно (и даже получить из-за этого дыру в безопасности), а Option - нет.

Потому что указатель можно использовать неправильно (и даже получить из-за этого дыру в безопасности), а Option - нет.

О как. То есть логические ошибки, приводящие к уязвимостям, невозможны? Прям совсем-совсем?

Потому что указатель можно использовать неправильно (и даже получить из-за этого дыру в безопасности), а Option - нет.

О как.

Ага.

То есть логические ошибки, приводящие к уязвимостям невозможны?

Не понимаю, что натолкнуло тебя на такое предположение. Они возможны, естественно. Но с нулевым указателем возможны не только они.

Не понимаю, что натолкнуло тебя на такое предположение. Они возможны, естественно. Но с нулевым указателем возможны не только они.

Безусловно. Но, повторю свой тезис — если тест все равно придется писать (или мы какую-нибудь функцию проверки JWT-токена в продакшон прям без теста пустим?), то где обещанная экономия времени на тестах?

если тест все равно придется писать (или мы какую-нибудь функцию проверки JWT-токена в продакшон прям без теста пустим?), то где обещанная экономия времени на тестах?

Ну, во-первых, успешное прохождение тестов не означает правильную прогрмму («тестирование доказывает наличие ошибок, но не их отсутствие», да), но, по сравнению с Си++, в Rust наличие целого класса ошибок исключено (или сведено к минимуму, см. выше), поэтому за те же деньги то же время ты получаешь продукт лучшего качества. Во-вторых, зависит от того, что что ты тестируешь: если исключительно прикладную логику - естественно, выигрыша (по количеству тестов) не будет. Но если что-то похитрее (реакцию на мусорные указатели, например) - то в Rust такие тесты не нужны.

О чем, собственно, и речь - Rust позволяет не отвлекаться от прикладной логики на всякую фигню типа управления памятью.

Ну, во-первых, успешное прохождение тестов не означает правильную прогрмму («тестирование доказывает наличие ошибок, но не их отсутствие», да), но, по сравнению с Си++, в Rust наличие целого класса ошибок исключено (или сведено к минимуму, см. выше), поэтому за те же деньги то же время ты получаешь продукт лучшего качества.

Вот с этим я и не согласен, потому что тест Option от теста ptr/NULL не отличается вообще ничем. Только два валидных значения, и тебе оба нужно проверить. Поведение в обоих случаях абсолютно детерминированно.

Выигрыш только в одном — если ты не тестируешь функцию, а там баг, то ты не получишь SIGSEGV. Что, иногда, бывает значительно хуже, чем если бы ты его получил. А иногда не бывает, как повезет.

Во-вторых, зависит от того, что что ты тестируешь: если исключительно прикладную логику - естественно, выигрыша (по количеству тестов) не будет. Но если что-то похитрее (реакцию на мусорные указатели, например) - то в Rust такие тесты не нужны.

А можно пример реально полезного теста на мусорный указатель? Потому что я не могу себе представить, зачем он может быть нужен, если только ты какие-нибудь там canary в glibc не тестируешь. В любых других ситуациях слишком высока неопределенность.

Вот с этим я и не согласен, потому что тест Option от тест ptr/NULL не отличается вообще ничем.

А весь остальной текст ты пропустил? Ну, дело твое.