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

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

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

  1. SadKo

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

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    Ну народ уже словил попаболь при переходе с gcc4 на gcc5 (касательно С++). По идее, переход с gcc6 на gcc7 тоже должен ещё одну попаболь добавить. Но в целом жить можно.
    У меня в системе из коробки идёт 4.8.5, но также доступны и 5, и 6 gcc. Но, видимо, не спроста дистростроители не торопятся переводить всю систему на gcc5+, хотя Leap-ветка, вроде, уже при помощи gcc6 собирается.
     
  2. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    2.596
    Даже если соблюдать все эти правила конкретного скрипта, это не решит проблему. Первая из них - RC ошибки. Они не решаются или предсказываются алгоритмически, так же эти сотни правил не помогут их избежать. Какого бы индуса не заставили выучить все эти правила, он всё равно накосячит, а косяк будет именно на уровне асинхронной работы с данными(RC). Это никак не резолвится правилами или автоматикой. Алгоритмические ошибки - к ним правила оформления скрипта отношения не имеют :preved:
     
    X-Shar нравится это.
  3. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    2.596
    SadKo,

    > Вы неправильно прочитали: математика не ломается.

    Нужно наверно поправить. Математика и прочее всё не ломается, если на это не обратили внимание и нет такой задачи. По умолчанию любая система уязвима.
     
  4. X-Shar

    X-Shar Member

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

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

    Так-вот, ну написал я, сделал свои тесты простые. Все ОК, можно сдавать заказчику подумал я.

    Отдали мою ФС крутым тестерам, которые обнаружили не много, не мало около 5000 ошибок. Блин там сама ФС около 2000 строк, если не считать драйверы носителей. Я ухайдокался фиксить, то неверный код ошибки вернет, то неработает там что-то. Несколько раз ложили вообще систему, короче изнасиловали мой проект как могли, даже вспоминать больно. :dntknw:

    Вот пример хороших тестов, но чтобы тесты были хорошими, тестировщику нужно знать как работает проект и сервисы проекта. А что-бы это знать, нужна документация. Если нет нормальной документации, как вы будете писать тесты ?
     
  5. SadKo

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

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    В нормальном Agile обычно тестировщики сидят рядом с разработчиками, и наличие документации обычно скорее опция, чем необходимость.
     
  6. X-Shar

    X-Shar Member

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

    Да, такое практикуют, я например могу тестить чужой код, мой код также кто-то может тестить.

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

    Поэтому часто тесты пишут сторонние организации, которые только тестами и занимаются и ничем больше.

    Ну либо нужен специальный отдел тестировщиков.
     
  7. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.325
    Адрес:
    Fryazino
    Каких?
    Я знаю что Юнит-тесты пишутся прямо в коде. Зачем дёргать разработчиков? Это прямая обязанность разработчика писать тесты. В документе SRS или ТЗ вы планируете процент покрытия тестами. Далее менеджер должны заложить время на разработку тестов. Оно в 1,5-2 раза больше чем на написание кода. И далее уже разработчик не дёргается, а планомерно пишет тесты и код. Причём в зависимости от методологии тесты можно писать до, так и после.
    При объеме в 1,5-2 раза один тестировщик ничего не сможет сделать и даже отдел. Поэтому юнит-тесты и должны писать разработчики.

    Если приём сдаточные тесты, то они пишутся по ТЗ. В Agile это карты ...
    Если юнит-тесты то они пишутся по названию метода либо по его внутреннему устройству. Черный ящик и белый ящик соответственно.
     
  8. X-Shar

    X-Shar Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    118
    Что-то типо IBM RTRT, есть его аналоги. Но не у всех есть сертификаты.

    Данные программы помогают автоматизировать разработку тестов, например подача на функции параметров и т.д.

    Можно писать как динамические тесты, так и модульные.

    Вручную тестировать можно долго, если проет громадный. :)
     
    Pavia нравится это.
  9. TermoSINteZ

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

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.134
    Адрес:
    Russia
    так же есть автоматические тесты, из открытых утилит. ну например Driver Verifier. В проекте, где есть разработка драйверов - очень полезная вещь. И можно внедрить на сервер автоматического тестирования - сразу после создания билда идет его проверка как на обычный запуск, так и этой тулой в разных режимах.
     
  10. TermoSINteZ

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

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

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    282
    Обсуждение корпоративного организационного устройства какое отношение имеет к теме?
    У меня образование "Управление организацией", могу вам сказать, что организационные иерархии выстраиваются вовсе не из соображений по снижению ошибок в коде ))
    Здесь задачи по наращиванию инструментов контроля и наличие управляемости рабочим коллективом, тестировщики выполняют задачи по контролю за работой программеров для их манагеров, что-то вроде аудиторов в бухгалтерии. Подражание корпоративной иерархии это уже карго культ, о котором писал Стив Макконнелл в работе под названием "Professional Software Development".

    Давайте придерживаться понятия "безопасное программирование".
    Что касается проверки входных параметров, опять же рассмотрено Стивом Макконнеллом подробно в книге Совершенный код "по мере возможности делайте интерфейсы программными, а не семантическими", "Любой аспект интерфейса, который не может быть проверен компилятором, потенциальный источник ошибок.... Старайтесь преобразовывать семантические элементы интерфейса в программные, используя утверждения (assertions)...".
    Здесь можно увидеть простой принцип, семантику конвертим в программные утверждения. Двойная деаллокация чекаться должна через assert и это разумно. Ответ на вопрос ранее озвученный "как я узнаю, что произошла ошибка".

    P.S. Кому интересна тема корпоративной организации, вот интересная статья http://hbr-russia.ru/management/korporativnyy-opyt/a11165/ Можно найти на торрентах если заинтересует вступление. Меня вдохновила в свое время.
     
    Последнее редактирование: 22 фев 2018
    TermoSINteZ нравится это.
  12. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    2.596
    TermoSINteZ,

    Вот вы это всё хорошо обсуждаете и возникает вопрос. Вы никогда за всё время не написали ни строки кода. Но вы его обсуждаете как будто в теме. Раскажите лучше кто вы.
     
  13. RET

    RET Well-Known Member

    Публикаций:
    17
    Регистрация:
    5 янв 2008
    Сообщения:
    797
    Адрес:
    Jabber: darksys@sj.ms
    Indy_, да эт местное элито :) ..... начитанное наших с Вами постов && оказавшиеся в модерах, странно но опять, я по этой теме вообще молчу, имхо бредотопик, далекий от релизов etc
     
  14. X-Shar

    X-Shar Member

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

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

    Опять-же вернулись к корпоративной организации. :) Если тестировщики выполняют карательные функции, то нахрен эти тестировщики нужны.

    Реально-же тестировщики, это неотьемлимая часть разработки практически любого софта, без них ну никак. :)
     
  15. X-Shar

    X-Shar Member

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

    Видел организации, где считают строчки кода в день. Ну бред, если я напишу 1000 строчек, то типо работаю, ога. :)

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

    Но разумеется еще и влияют кадры, если мракобесов набрать, никакая структура не поможет. :)
     
  16. unc1e

    unc1e Active Member

    Публикаций:
    2
    Регистрация:
    28 июл 2017
    Сообщения:
    291
    Indy_,
    > Раскажите лучше кто вы
    А что вы ожидаете услышать от него? Уж очень общий/фундаментальный вопрос.
     
  17. TermoSINteZ

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

    Публикаций:
    1
    Регистрация:
    11 июн 2004
    Сообщения:
    3.134
    Адрес:
    Russia
    Indy_, RET,
    эт вы ребят говорите говорите, да не заговаривайтесь. Предупреждение обоим за оффтоп.
     
  18. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.594
    во многом всё тобой описанное есмь недостижимый идеал. к примеру, прописать кучу обработчиков ошибок == еть не просто муторно, еть может уронить производительность кода в Зеро. А при всём сём..

    1. сделать 100500ую защиту от дурака НЕВОЗМОЖНО.
    2. аки б ты тщательно не строфал свой код == он (твой код) подгружает бинарники/скрипты/вм-ки от третьих сторон, то бЫшь в твоей вариации разработки нужно ладить кучу чужого кода. И не надо говорить, мол-де ты токЪ проверенный используешь: житухи тебе не хватит на проверку всего и вся.
    3. имеют место быть косяки железок и от них опять
    НЕВОЗМОЖНО 100500ую защиту.
    4. проблемы лицух: в коде может использоваться проприетарный дравер/кодек/.. третьей стороны и си лицухи могут не просто ограничивать диапазон возможных решений, они ещё могут меняться в одностороннем порядке.
    5. магия опенсорца нам допомо}|{Э 777 :) увы и @}{, ни }{¥.. == нормальная дистра линя сейчас напичкана проприетарщиной, а труЪ линь можно себе поставить, если захотел порыдать :grin::sarcastic_hand::laugh1::crazy::hunter:

     
  19. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.594
    upload_2018-4-16_14-50-54.png
    в защиту РМН приведу забавный пример..
     
  20. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    282
    UbIvItS,
    И? OpenSSL хорошая разработка.
    Есть фанаты сверх-надежных решений, которые создали LibreSSL с более параноидальным подходом к безопасности в работе со строкам/памятью.
    Именно об этом я и веду речь.
    Я сам не использую OpenSSL и собрал билд Tor'а через LibreSSL, в своих проектах отдаю предпочтение MBEDTLS ранее известному как PolarSSL.