The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Инициатива по созданию порта PostgreSQL на языке Rust, opennews (?), 09-Янв-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Инициатива по созданию порта PostgreSQL на языке Rust"  +2 +/
Сообщение от Аноним (-), 09-Янв-17, 12:10 
То есть сейчас имеется код на C в котором есть проблемы с памятью.
Он может быть автоматически переведён на другой язык, а затем скомпилирован в машинный код и проблемы исчезнут?
Было бы неплохо всегда так компилировать.
Ответить | Правка | Наверх | Cообщить модератору

25. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 09-Янв-17, 12:17 
> То есть сейчас имеется код на C в котором есть проблемы с
> памятью.
> Он может быть автоматически переведён на другой язык, а затем скомпилирован в
> машинный код и проблемы исчезнут?
> Было бы неплохо всегда так компилировать.

Есть вариант что не даст откомпилировать, другой вопрос что после этого делать, так как исходя из озвученного, нужно будет поправить C-код, который даёт ошибку при трансляции, а это уже не пахнет автоматизмом.

p.s. В своё время firebird был полностью переписан на C++.

Ответить | Правка | Наверх | Cообщить модератору

29. "Инициатива по созданию порта PostgreSQL на языке Rust"  +2 +/
Сообщение от Аноним (-), 09-Янв-17, 12:39 
Об этом Якобс не думает, не царское это дело.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

50. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Яйцассыром (?), 09-Янв-17, 13:43 
> Он может быть автоматически переведён на другой язык, а затем скомпилирован

Да, на данный момент, исключительно с помощью магии.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

62. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноненамус (?), 09-Янв-17, 14:12 
https://github.com/jameysharp/corrode
Ответить | Правка | Наверх | Cообщить модератору

147. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 09-Янв-17, 20:17 
> и проблемы исчезнут?

Думаю, имеется ввиду другое. Проблемы не исчезнут. Но проблемы уровня "нас плимели через переполнение буфера" заменятся на проблемы "вчера внезапно возрасла нагрузка с такого-то ip, после чего система упала со стектрейсом в 500 строк".

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

202. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 09-Янв-17, 23:42 
> Думаю, имеется ввиду другое. Проблемы не исчезнут. Но проблемы уровня "нас плимели
> через переполнение буфера" заменятся на проблемы "вчера внезапно возрасла нагрузка с
> такого-то ip, после чего система упала со стектрейсом в 500 строк".

И часто ты видишь поимение серверов через переполнение буфера? Вроде сейчас намного чаще имеют через вебприложения. А то что буфера не переполняются - вебне почему-то не очень помогает.

Ответить | Правка | Наверх | Cообщить модератору

201. "Инициатива по созданию порта PostgreSQL на языке Rust"  –1 +/
Сообщение от Аноним (-), 09-Янв-17, 23:40 
> Было бы неплохо всегда так компилировать.

Так компилируй, с -fsanitize=address и что там тебе еще надо. А то что скорость получится go-образная - сам понимаешь, дополнительные проверки.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

207. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 10-Янв-17, 00:32 
> Так компилируй, с -fsanitize=address и что там тебе еще надо. А то
> что скорость получится go-образная - сам понимаешь, дополнительные проверки.

А можно использовать наработки в компиляторах за последнии 40 лет и добавить в ЯП фишки, позволяющие делать проверки в компайлтайме. Потому как не только софт за эти годы стал сложнее, но и железо мощнее и как-то глупо пользоваться этими мощностями только для проверок во время выполнения.

Ответить | Правка | Наверх | Cообщить модератору

229. "Инициатива по созданию порта PostgreSQL на языке Rust"  +1 +/
Сообщение от 111 (??), 10-Янв-17, 09:17 
Сразу видно человека, который не компилировал бустопроги.
Ответить | Правка | Наверх | Cообщить модератору

256. "Инициатива по созданию порта PostgreSQL на языке Rust"  +1 +/
Сообщение от Аноним (-), 10-Янв-17, 15:08 
> Сразу видно человека, который не компилировал бустопроги.

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

Ответить | Правка | Наверх | Cообщить модератору

248. "Инициатива по созданию порта PostgreSQL на языке Rust"  –1 +/
Сообщение от iPony (?), 10-Янв-17, 12:46 
Ну так почему C++ так долго компилируется - вот поэтому.
В С++14 можно создать даже класс с конструктором, который будет выполняться во время компиляции.
Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

261. "Инициатива по созданию порта PostgreSQL на языке Rust"  –6 +/
Сообщение от Аноним (-), 10-Янв-17, 15:47 
> в ЯП фишки, позволяющие делать проверки в компайлтайме.

Я конечно понимаю что CS у россиян не в почете, но до того как умничать - наверное азы типа halting problem стоит почитать? Полный анализ поведения программы выполнить невозможно. Тюринг предствил математическое доказательство, взяв для примера довольно простой случай, изучающий завершится ли программа за конечное время. Поэтому если кто-то верит в всемогущесть статического анализа - он, простите, нуб и ламак, который не соизволил читануть азы по минимуму, но мнение имеет.

> Потому как не только софт за эти годы стал сложнее, но и железо мощнее
> и как-то глупо пользоваться этими мощностями только для проверок во время выполнения.

У проверок во время выполнения есть определенная фича. Их Тюринг не жмет. Ну то-есть если вы видите фактический доступ к адресу памяти который за границей массива - это одно. А попытки в статике проанализировать может ли в принципе эта программа взять 101-й элемент массива при том что их всего 100, при всех мыслимых манипуляциях - то же самое что halting problem, вид сбоку. Поэтому таки или будут проерки в рантайме что индекс от нуля до сотни и они сожрут время, или проверок таки не будет и можно будет сунуться в 101-й элемент и даже что-то получить. А какие еще варианты есть???

Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

266. "Инициатива по созданию порта PostgreSQL на языке Rust"  +2 +/
Сообщение от Аноним (-), 10-Янв-17, 16:22 
> Поэтому если кто-то верит в всемогущесть статического анализа - он, простите, нуб и ламак, который не соизволил читануть азы по минимуму, но мнение имеет.

Убрать все обычные циклы, оставить только foreach (range-based for loop) и добавить гибридные циклы с условием и параметрами обхода. И тогда не получится  залезть в 101 элемент + можно добавить автоматические оптимизации, ведь компилятор будет значть что хочет программист. Статический анализ может и не всемогущ, но при правильном проектировании можно избежать всех ошибок в комплтайме.

Ответить | Правка | Наверх | Cообщить модератору

290. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 14-Янв-17, 01:56 
> Убрать все обычные циклы, оставить только foreach (range-based for loop) и добавить
> гибридные циклы с условием и параметрами обхода.

И все бы ничего, но это уронит скорость выполнения. Примерно настолько же насколько и явный bounds checking в рантайме. Догадаешься с трех раз почему? Проверки на вшивость в рантайме или есть или нет. Третьего не дано. Понимаешь, у CPU нет такого понятия как foreach. Он вообще другими сущностями оперирует. И ты (или твой компилер/рантайм) или таки провалидируете что вы не лезете в левую память или таки есть шансы поиметь проблем. Халявная по скорости защита памяти на уровне железа - работает с гранулярностью страницы, и то заточено на защиту ОС от софта и процессов друг от друга. А части процесса друг от друга так защищать уже несколько накладно.

Ответить | Правка | Наверх | Cообщить модератору

267. "Инициатива по созданию порта PostgreSQL на языке Rust"  +5 +/
Сообщение от Аноним (-), 10-Янв-17, 16:27 
>> в ЯП фишки, позволяющие делать проверки в компайлтайме.
> Я конечно понимаю что CS у россиян не в почете, но до
> того как умничать - наверное азы типа halting problem стоит почитать?

Что, кроме тюринга ничего больше не знаешь? А моежт еще стоит, до того как влезать с тюрингом где можно и нельзя, азы компайлостроения почитать?

> Полный анализ поведения программы выполнить невозможно.

Где ты увидел "полный анализ", болезный? Ну и следуя твоей логике, вообще никакие проверки не нужны, ведь они не полные.

> Тюринг предствил математическое
> доказательство, взяв для примера довольно простой случай, изучающий завершится ли программа
> за конечное время.

Ну давай, сформулируй для частного случая анализа, я хоть посмеюсь.

> Поэтому если кто-то верит в всемогущесть статического анализа
> - он, простите, нуб и ламак, который не соизволил читануть азы
> по минимуму, но мнение имеет.

А ты самокритичен, этого не отнять.

> А попытки в статике проанализировать
> может ли в принципе эта программа взять 101-й элемент массива при
> том что их всего 100, при всех мыслимых манипуляциях - то
> же самое что halting problem, вид сбоку.

Cпасибо, давно так не смеялся.

> У проверок во время выполнения есть определенная фича. Их Тюринг не жмет.

Ну и сиди на своем питоне и прочих базиках, как раз для таких экспертов и знатоков.


Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

291. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 14-Янв-17, 02:09 
> Что, кроме тюринга ничего больше не знаешь? А моежт еще стоит, до
> того как влезать с тюрингом где можно и нельзя, азы компайлостроения почитать?

А что, кто-то смог сотворить чудо и сделать bounds checking без просадок скорости?

Ну вот смотри, есть у меня массив записей, число записей задается на основе внешних данных. Значит на фазе компиляции это никак невозможно просчитать, а всякие foreach будут вынуждены делать тот же bounds checking вид в профиль. Или его можно будет нае...ть, на выбоо.

> Где ты увидел "полный анализ", болезный? Ну и следуя твоей логике, вообще
> никакие проверки не нужны, ведь они не полные.

Я просто к тому что напирание на безопасность в этом случае как-то излишне оптимистично. Статические анализаторы штука хорошая, но и близко не панацея. К тому же вебмакаки показали много чудных способов как позволить разломать сервер вообще не пуская хакеров в управление памятью. Да и Bobby Tables любителям сабжа приветы передавал.

> Ну давай, сформулируй для частного случая анализа, я хоть посмеюсь.

ИМХО, невозможно заранее статически полностью проанализировать конструкции которые динамически выделяются в рантайме, например на основе входных данных. А потуги сделать нечто типа foreach уронят скорость, потому что это более не будет лобовым доступом к памяти без дополнительных приседаний.

> А ты самокритичен, этого не отнять.

И это тоже. Правда я не верю в всемогущесть статического анализа.

> Cпасибо, давно так не смеялся.

Ну это несомненно был мощный технический аргумент вашей правоты.

> Ну и сиди на своем питоне и прочих базиках, как раз для
> таких экспертов и знатоков.

А в этом месте смеялся уже я. Васик я видел где-то в конце 80-х чтоли.

Ответить | Правка | Наверх | Cообщить модератору

279. "Инициатива по созданию порта PostgreSQL на языке Rust"  +2 +/
Сообщение от Аноним (-), 11-Янв-17, 15:50 
1. Если программист написал настолько сложную программу, что он сам для себя даже примерно не может сказать, как она поведёт себя (остановится или нет, где может упасть), то зачем он её вообще писал? Если на практике мы чаще всего имеем дело с программами, написанными людьми и читаемые людьми, то почему сразу вспоминают Тьюринга и какие-то сферические в вакууме программы?

2. Для многих алгоритмически неразрешимых задач и задач с экспоненциальной сложностью давно уже разрабатывались эвристические методы, чтобы хоть как-то приближённо решать эти задачи. Даже проблему остановки можно попытаться решить с некоторой степенью глубины анализа. Трансляция из языка в язык - тоже довольно реальная задача для программ, встречающихся на практике (написанных и понимаемых людьми).

Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

280. "Инициатива по созданию порта PostgreSQL на языке Rust"  +1 +/
Сообщение от Аноним (-), 11-Янв-17, 18:04 
> то почему сразу вспоминают Тьюринга и какие-то сферические
> в вакууме программы?

При этом еще благополучно забывают (после того как не знают, такое вот у них отличное качество преподавания СS в Не Этой Стане :) ), что все это применимо в первую очередь к невозможности создания _одной универсальной_ машины для анализа _всех возможных_ машин со _всеми возможными_ вводами.
А то, что все возможные вводы в реальном мире не нужны и их можно хорошо так отсечь, да и при анализе, если что, выдать "этот вариант проанализировать не могу, прошу уточнений, правки или оверрайда!", так для этого хоть что-то понимать надо, а не повторять мантры.

Тот же примерчик с индексом отлично показывает "понимание" темы данным индивидом. Потому как на самом деле такие левые индексы прилетают не по либастралу, а с вводом пользователя, либы и т.д. И их придется проверять по-любому.
Только в отличие от "best-practice" проверок по два-три раза подряд, как в том же системды, можно ограничиться одной проверкой и воплями компилятора при отсутсвии оной.

И вообще, анализизируют обычно не все возможные  варианты, а только возможность отклонений от сценария, описанного програмистом. Т.е. достаточно найти место, где может прилететь тот же левый индекс неопределенной величины и выдать предупреждение, а не пытаться почему-то представить себе все мыслимые манипуляции.

Только все это метание бисера - данный индивид или объявит, что "вы усе врети!" или что он, такой велики и неповторимый, все это на самом деле уже знал и просто так своебразно троллил )


Ответить | Правка | Наверх | Cообщить модератору

281. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Andrey Mitrofanov (?), 11-Янв-17, 18:46 
>> то почему сразу вспоминают Тьюринга и какие-то сферические
>> в вакууме программы?

(:1)

> в первую очередь к невозможности создания _одной универсальной_ машины для анализа _всех возможных_ машин со _всеми возможными_ вводами.

[[Я не распарсил длинного последовавшего текста. Наверное, с сарказмотэгами опять непроходимость где-то, поэтому применю сию----^^^ строку к длиннотам ниже. Хотите считайте продолжением глумления над предыдущим оратором, хотите -- над обоими (новооткрытый тэг ниже именно про это).]]

> том же системды, можно ограничиться одной проверкой и воплями компилятора при
> отсутсвии оной.
> И вообще, анализизируют обычно не все возможные  варианты, а только возможность
> отклонений от сценария, описанного програмистом. Т.е. достаточно найти место, где может

Вы назовёте уже изнывающей публике универсальный ЯП [с транслятором, понятно], таки проверяющий Ваш "возможный сценарий" для _своих_ входных данных (всех и любых програм на нём, языке) -- чтоб все коды, что "собрались" уже-таки были "безошибочны, мамой клянусь", да?

---Вы прочитали применение (:1) для познания рекурсии.
...Объявляю тэг(*2) #форумная-ЦС (*3) Открытым! ура.

(*2) #форумная-криптография, в продолжение,  да:
  http://www.opennet.ru/openforum/vsluhforumID3/109852.html#45
  http://www.opennet.ru/openforum/vsluhforumID3/109704.html#6
  http://www.opennet.ru/openforum/vsluhforumID3/106299.html#14
  ...итдпттптптптпт
(*3) Как это по-русски-то правильно, кстати... Не "программирование" же!?

> Только все это метание бисера - данный индивид или объявит, что "вы
> усе врети!" или что он, такой велики и неповторимый, все это
> на самом деле уже знал и просто так своебразно троллил )

Форумное "толкачём в ступе". Тэг не нужен, оно везде.

Ответить | Правка | Наверх | Cообщить модератору

298. "Инициатива по созданию порта PostgreSQL на языке Rust"  +/
Сообщение от Аноним (-), 02-Фев-17, 00:00 
>> в ЯП фишки, позволяющие делать проверки в компайлтайме.
> Я конечно понимаю что CS у россиян не в почете, но до
> того как умничать - наверное азы типа halting problem стоит почитать?
> Полный анализ поведения программы выполнить невозможно. Тюринг предствил математическое
> доказательство, взяв для примера довольно простой случай, изучающий завершится ли программа

Существует такая вещь, как SMT-solver'ы. Они могут проверить граничные условия, заданные для какой-то функции и её частей.

Язык Ada Spark https://en.wikipedia.org/wiki/SPARK_(programming_language) такое может
и пример проекта http://blog.adacore.com/tetris-in-spark-on-arm-cortex-m4

Для языка Си давно уже существует Frama-C https://en.wikipedia.org/wiki/Frama-C который точно так же позволяет гарантировать некие условия, выполняющиеся функцией.

Эти вещи не применяются в разработке массового ПО, в том числе опенсорцного потому, что господа сишные хакеры в большинстве своём малограмотны в CS и не "заточены" под долгую кропотливую работу, дающую корректный результат. Также, Frama-C предполагает, что в некоторых случаях разработчик будет пользоваться Coq, а это уже очень требует очень высокий уровня владения довольно специфичной математикой.

Военного происхождения Ada Spark - простой, как кирпич и ничего такого не требует, хотя он и менее мощен, чем научная французская Frama-C, зато язык Ada гораздо более стандартизирован, чем Си, и от него не стоит ждать неожиданностей. Но с ним другая беда - во-первых, он не си, а паскаль, там видите ли begin и end, от вида которых у байтогрызиков начинается фрустрация. Во-вторых, в бесплатном виде он распространяется только под GPL, а большая часть проектов имеет двойное лицензирование - если они хоть кому-то будут продаваться за деньги. Коммерческий же Spark стоит дорого, примерно как четыре колеса от джипа, но у байтогрызов зачастую нет не то, что джипа, а даже и тоёты, они на велосипедах ездят, с зеркалками, интересные проекты делают. Денег у них нет.

Поэтому пользователи OSS так и будут ловить CVE, к ним будет лезть NSA и все прочие кибержулики. Потому что во главу ими была поставлена хакерская скорость разработки, а не промышленная надежность. Пришёл упорный инженегр Линус, быренько наrовнякал реализацию Posix, раньше Столлман доделал своё, и теперь нам всем с этим жить, мода задана на много лет вперёд. 12309! Я думаю, что финскому жирному пингвину помогли придти к успеху те самые люди, про которых Сноуден рассказывал. Чем больше дыр и ненадёжного софта - тем лучше для этих. Люди работают, понимать надо.

Более того, поскольку программистская культура в общем-то едина, те же самые скоростные багоделы пишут и коммерческий софт. Это модно.

PS: доказанное ядро на Ada Spark, https://muen.sk/
Понимаете ли, на паскале с пред- и пост- условиями написали ядро, без дырок.

PPS: по бенчмаркам на https://benchmarksgame.alioth.debian.org/u64q/ada.html Ada работает примерно со скоростью Си и иногда обгоняет С++, причём Ada у них старая, 2005, а не 2012

Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру