1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Что такое безопасное программирование ?

Тема в разделе "WASM.ZEN", создана пользователем X-Shar, 17 фев 2018.

  1. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    282
    Зачем так флудить и превращать тему в срач?

    Вам было сказано четко и по делу, о существовании инструментов облегчающих контроль за ресурсами, которые применяются в самых распростренных решениях, таких как LibreSSL, OpenSSL, OpenVPN, которые есть в каждом мобильном телефоне и десктопе. Инструменты облегчающие разработку не созданы для маскировки ошибок. Они созданы для минимизации человеческого фактора, для исключения ошибок связанных с поздними доработками, когда тщательно выверенный код изменяется в одном месте, а освобождение ресурсов происходит в разных точках, и добавление нового malloc нужно снабдить серией free в разных местах.

    На месте администрации, я бы отправил в бан за неуважение к участникам дискуссии.
     
  2. X-Shar

    X-Shar Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    118
    С этим согласен, но вот то-что архитектор должен уметь кодить несоглашусь.

    Вот пример в авиации даже, архитектор знает как устроен самолет и рассматривает самолет как некий "черный ящик", ему не важно, что какой-то там кодер сделал маллок или фри. Его задача, чтобы система работала в целом.

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

    Это перевод зарубежного стандарта, есть более интересные стандарты для авияции, которые как-раз и нужны для безопасной разработки, стандарты Arinc например, мне очень нравится. :)

    КТ-да ничего на самом деле и не требуют, вернее они дают какие-то базовые советы. А как это делать, решать в самой организации. Вообще мало понятно почему для сертификации взяли именно этот стандарт, вернее понятно, что это нужно для выхода на международный рынок, но тем не менее и в РФ были наработки похожего стандарта. :)

    В любом случае, как мне кажется, это лучше, чем когда разрабы кодят что-то там. Никаго описание, не комментариев, ничего нет. Да и непонятно как тестировать потом все это ? :)
     
  3. TermoSINteZ

    TermoSINteZ Синоби даоса Команда форума

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.134
    Адрес:
    Russia
    До бана далеко, но рид-онли свой он получит
     
  4. TermoSINteZ

    TermoSINteZ Синоби даоса Команда форума

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.134
    Адрес:
    Russia
    Почему вы думаете, что так только в России или еще где в мелких конторах и прочее.
    Да так вообще-то много где. Я даже могу сказать что такой гигант софтостроения, как AMD этим грешит (хотя последние года два там конечно закрутили гайки, хоть и не везде).

    Но модель работы больших корпораций сильно отличается от стартапов, или маленьких фирм. В крупных компаниях нет понятия "Этот чувак спец, мы его оставляем не смотря ни на что" там все в общем то считаются одинаковыми - принцип "незаменимых людей нет". Все задачи довольно мелко бьются. Ну и тестирование налажено лучше. Да и процесс работы построен строже. Особенно трепетно следят за веткой Mainline. Считается что майнлайн - это лицо компании. Если он не собирается или крешится, не проходят тесты - то считайте у вас нет продукта. А значит и кастомеру показать нечего. Примерно такой подход. По этому в майнлайн льется все очень аккуратно и продуманно. Они даже содержат отдельный штат \ команду которая ответственно за вливание и мерж чейнджлистов в майнлайн. И очень часто майнлайн не равен основной ветке девелопмента. Как правило майнлайн меньше по фукнциональности от текущего момента времени.
    Ну даже если рассматривать процесс разработки и залития в ветку девелопмента (стейдж) . Там тоже, без кодревью и пройденных тестов (как билд так и запуск) никто не даст тебе залить . Не говоря уже о том, что в кодревью обязательно участие архитектора и лида из твоей тимы. не говоря об остальных кто вовлечен в фичу. А иногда даже нужно пригласить более глобального архитектора, заведующего всей кухней .
    Вы скажете процесс слишком долгий, ревью в пару дней минимум не говоря об итерациях. Но по факту получается быстрее и дешевле. Код видят несколько человек, что уменьшает вероятность ошибки уже на ранних стадиях, а автоматические сборки и тесты дают возможность еще более уменьшить вероятность ошибки. Гораздо дороже - исправлять баг потом и искать регрессию (а это хорошо еще что сервер билдов хранит каждую сборку на каждый коммит). И я не говорю о том, когда баг просочился до уровня кастомера.
     
    X-Shar нравится это.
  5. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    TermoSINteZ правильно пишет. Чем строже процесс девелопмента, тем лучше и безопаснее выхлоп.
    При этом, строгость заключается не в бюрократии, которую так любят разводить в постсовке (писать отчёты на отчёты на отчёты), а именно в том, что в курсе дела сразу несколько человек, и если один что-то упустил, то хотя бы другой из остальных это заметит. При этом, тесты пишутся не столько для того, чтобы проверить работоспособность новой фичи, а именно убедиться в том, что старые фичи не сломались. И, мало того, механизмы отладки и автоматизированного тестирования тоже разрабатываются из специфики проекта, и далеко не все популярные фреймворки под это дело подойдут.

    По своему опыту убедился, что если кастомный софт ставится нескольким заказчикам и пилится под каждого индивидуально, то проще иметь ветку всего софта для кажого заказчика отдельно, и при этом иметь основную ветку для продукта, в которую сливаются актуальные оттестированные изменения. При этом, изменения от одного заказчика другому переносить нужно именно через основную ветку продукта. То есть, правильное построение системы деплоя кода в ветки спасает от кучи косяков и геморроя в будущем. И также спасает от ситуаций, когда ставится новое ПО, а из-за расхождения версий отдельных компонент в совокупности они перестают работать.
     
    TermoSINteZ и X-Shar нравится это.
  6. superakira

    superakira Guest

    Публикаций:
    0
    На такой подход надо решиться. Я серьезно. Те с какого-то момента надо вводить работау с тикетами, работа с досками, работа с кодом.
    1. Разделение веток (мастер-дев-фичи-итд)
    2. Билд сервер (или серврера)
    3. Тестовое окружение (прогон тестов на виртуалках)
    4. Написание тестов, покрывающих кейсы использования (например на базе гтестов)
    5. Тестирование на целевых ОС, а не у меня на машине работает.
    6. Пуллреквесты, ревью.
    7. Кодинг-стайл (вот норм который, например от Qt и запил его под себя).
    8. Документирование кода.
    9. Кодить не через жопу (алгоритмическая образованность итд).

    Это все дорого. Тупо дорого. Но в итоге конечно выхлоп лучше. Но людям такое не сделать, если они не варились в командах, которые так работали.

    По факту, так почти все работают, кто делает коробочные продукты. По другому это не работает.
     
    X-Shar нравится это.
  7. X-Shar

    X-Shar Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    118
    Все зависит от компании, если компания небольшая, то вполне реально. Ну-да очень тяжело, я сейчас работаю в небольшей фирме, мы как-раз и пытаемся работать по похожей схеме.

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

    Если-же организация, это какая-то корпорация, или завод и они изначально так не работали, то там уже и не получится так работать, либо нужно затрачивать лет так пять, на перестройку. :)
     
  8. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    Значит, в таком случае необходимо постепенно вводить изменения в процесс, а не рубить всё с плеча. То есть, если у вас масса кода не покрыта тестами, то выделяется время (например, один день в неделю), когда разработчики только тем и занимаются, что рефакторят код, уменьшая связанность модулей, и покрывают его тестами. Когда весь код покрыт тестами (и параллельно куча багов ещё сопутствующих пофиксена), приступаете к следующей итерации - разделение веток, continuous integration или что там ещё у вас запланировано.

    Перелопатить тонны старья, разумеется, куда сложнее и требует больше времени, нежели написание свежего с нуля.
     
    X-Shar нравится это.
  9. TermoSINteZ

    TermoSINteZ Синоби даоса Команда форума

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.134
    Адрес:
    Russia
    Обычно когда делаешь что-то один и никому не показываешь - то о багах и ошибках обычно не думают - показывать то некому. Написали код - о вроде работает .. и положили в дальний угол.

    ну и еще зависит на чем пишется.
    например на питоне ошибок будет меньше. Там много готовых и хорошо проверенных кирпичиков. По этому питон хорошо юзается в качестве демо и прочих вещей в том числе и проектов для единичных программистов
     
  10. RET

    RET Well-Known Member

    Публикаций:
    17
    Регистрация:
    5 янв 2008
    Сообщения:
    797
    Адрес:
    Jabber: darksys@sj.ms
    im., Было время, был - жил один чел, одновременно был и кодером сначала и архитектором, потом пошел в коммерс.. прошло время и его задолбали лавэ, захотелось стать кодером опять на фирме, но увы он уже учредитель, и увы не смог попасть, что называется в "струю", стал коммерс-[говно]архтектом- {кодером} и сам свое/suum cuique/ дело своё завалил.... Притча ой.
     
  11. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.325
    Адрес:
    Fryazino
    Если ни показать ни рассказать не можешь, то зачем такая программа нужна?
    А так полно правил ревью кода с последующим рефракторингом. Ищешь большие функции с кучей ифов и циклов. Если нашёл дробишь их на маленькие функции.

    Соблюдаешь стандарты аналогичные MISRA. К примеру то что конечный автомат должен кодироваться одной функцией. Не использовать goto. Делать проверку входных параметров. Инкапсулировать объекты так что бы не было публичных переменных, а обращение шло через методы. Соблюдать RAII где выделил память там и освобождаешь ибо если в разных местах будешь очищать, то непременно будут ошибки.

    Подобрать парочку статических анализаторов, что-бы они вам wornin'гов по на казали. И соответственно переписать код что-бы их не было.

    В конце концов начать тестировать код. Тестирование очень сильно помогает. Причём не абы как, а по науке с записью тестов кодом.
     
  12. TermoSINteZ

    TermoSINteZ Синоби даоса Команда форума

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.134
    Адрес:
    Russia
    а еще можете почитать Макконнелл. "совершенный код" . Много хороших советов дает - то о чем говорил Pavia
     
  13. Minzdrav

    Minzdrav Well-Known Member

    Публикаций:
    0
    Регистрация:
    21 мар 2017
    Сообщения:
    1.088
    X-Shar
    Безопасное программирование, это когда в буфер не отправляют больше
    циферок, чем размер буфера. (Меня Рмн научил).
     
  14. Minzdrav

    Minzdrav Well-Known Member

    Публикаций:
    0
    Регистрация:
    21 мар 2017
    Сообщения:
    1.088
    И есчо надо писать маленькие программки. И тщательно отлаживать.
    Чем меньше кода, тем меньше ошибок. Вот помнится, НетБСД, помещалась
    на дискете, долгое время. (Сейчас уже не знаю. Год назад ставил, из любопытства,
    но на серверах было полное запустение). А код её считался самым мудрым. И самым
    кросплатформенным.
     
  15. Minzdrav

    Minzdrav Well-Known Member

    Публикаций:
    0
    Регистрация:
    21 мар 2017
    Сообщения:
    1.088
    X-Shar
    Компилятор знать нужно! Чтобы ставить правильные флажочки
    для проверки кода. Он будет тебе делать замечания. А есчо
    флажочки чтобы он правильно транслировал в машинный код.
    Тоесть оптимизировал код.

    Вот если так делать будет безопасное программирование.
    А стандарты то всё ерунда.
     
    Последнее редактирование: 20 фев 2018
  16. X-Shar

    X-Shar Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    118
    Minzdrav, вы меня извините, но что-то вы такое страшное написали. :)

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

    Теперь про оптимизацию компилятора, страшная на самом деле штука, вот пример из жизни:

    Какое-то время работал в атомной отрасли. Нужно было сделать простенькую программу, которая в определенные моменты включает/отключает нагреватель по сети.

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

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

    Повезло, что технолог во время на месте оказался и вырубил все нафиг в ручную.

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

    Но вот вам пример, как софт может вызвать аварию на производстве. :)

    Если-же вы пишите софт, аля 1с для бизнеса, или какие-то вирусы, то-тут можно говнокодить сколько душе угодно, лишь-бы заказчик не воспроизвел ваши баги.

    Но сожрет ваш софт 8 гиг. памяти, а потом и упадет в конце рабочего дня, никто от этого не умрет. Пользователь все стерпит. :)

    А вот если ваш софт может повлеч какую-то аварию. Или в результате взлома/падения такого софта, будут огромные финансовые потери, тут уже задумываешься, как другие люди делают и о том-что стандарты не дураки пишут, а из своего опыта построения таких систем.

    Другое дело, что стандартов много и нет какого-то универсального решения. :dntknw:
     
  17. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    Всё верно. У меня gcc 4.8.5 математику хуже оптимизирует с -O3, чем с -O2, из-за того, что пытается код векторизовать (ха-ха!).

    Сделаю предположение, забыли где-то volatile впилить?

    Ну так это ж ентерпрайз (C)(R)(TM), можно жрать память тоннами, а обрабатывать по одной транзакции в час.
     
  18. Minzdrav

    Minzdrav Well-Known Member

    Публикаций:
    0
    Регистрация:
    21 мар 2017
    Сообщения:
    1.088
    Там написано в мануале что -O3, не желательная опция. Потому что начинает
    менять программу, в пользу оптимизации. Потому у вас и математика ломается,
    и реакторы атомные взрываются. GCC -O2, с GCC -O3, перепутал и всё, ###.
     
  19. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    Вы неправильно прочитали: математика не ломается. Математика тормозит с -O3 и нормально выполняется с -O2, по крайней мере в нативном коде.
    Какой можно из этого вывод сделать? Компиляторы по-прежнему не умеют векторизовать код (по крайней мере, ветка 4.8 GCC), нельзя им это дело доверять.
     
    X-Shar нравится это.
  20. X-Shar

    X-Shar Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    118
    Ога, но я тогда даже подумать немог, что компилятор может выкинуть целые строки кода.

    Честно с этими волатайлами до сех-пор плаваю. :dntknw:

    Вообще в системном программировании, два врага, это оптимизация компилятора и кеш процессора.

    Причем баги появляются плавающие и хрен их потом оттебажишь.

    У меня часто бывают проблемы с кешем, отключаешь кеш, все работает. Включаешь ничего не работает, но без кеша нельзя, тормоза еще-те появляются.

    Кстати флаг -O0, это не отключение оптимизации, компилятор все-равно будет оптимизировать.

    И еще программы по разному себя ведут, если компилировать в разных версиях gcc, например если все работает в gcc 4, то нефакт что все заработает после сборки в 5/6 версиях.