Быстрый старт в изучении C++ для относительно опытных программистов Basic

В этой ветке предлагаю обсуждать сходства и различия между C++ и Visual Basic.
Ну хотя бы для упрощения процесса изучения параллельного (дополнительного) языка для тех, кто уже относительно неплохо знаком с Visual Basic.
Ну просто как-то "не вкусно" начинать изучение совсем уж с нуля, когда, в принципе, уже и без того много знаешь (циклы, ветвления, указатели, видимость переменных ... ).

На самом деле, начал сейчас просмортр на ютубе курса по C++. Дядька очень толково и понятно всё объясняет, явно есть у него талант хорошего преподавателя.

Самые первые отличия, которые бросились в глаза, это:
- комменты обозначают двумя косыми чертами вместо апострофа,
- в конце каждой строки точка с запятой,
- все процедуры, функции, "тела" циклов ... в фигурных скобках,
- вложенные циклы можно описывать одной строкой,
- если переменная объявлена, но ей не присвоено значение, то она содержит случайный "мусор" из памяти, а не как у нас в бейсике, где сразу получает значение ноль или пустую строку,
- массивы с квадратными скобками вместо круглых,
- область видимости переменных ограничена фигурными скобками и причём неважно функция это, цикл или "тело" функции IF, а не как у нас область видимости переменных ограничена только функциями и процедурами.

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

Сказать по правде, лично мне сейчас C++ и его младший брат нужны, главным образом, для удобства изучения материалов MSDN.

0

Сообщение от Quiet Snow Это ошибка программиста. Если он напишет кривой код - это означает только одно, что он лоханулся и не формализовал задачу заранее(потому что мне не понятно как можно сделать всё по науке и криво вбить потом в код, это редкая халатность). По той же самой причине(по криворукости) неверный алгоритм может также не дать сбой и на обычных структурах языка, а потом выдать себя на важных данных. В указатели просто так не лезут, это всегда кастомная структура данных и всегда какие-либо требования к оптимизации кода. Поэтому вся эта "безопасность" - человеческий фактор.

Конечно человеческий, и чтобы облегчить жизнь человеку, как раз и придумывают концепции безопасного программирования. Не бывает такого что программист или команда сделали сразу сложную программу без ошибок. Такого просто не бывает. Что касается ручного управления памятью, решая задачу написания какого-нибудь парсера RTF/DOCX ты просто утонешь в куче разных кусочков, в которых тысячи зависимостей, и за каждой ты или команда просто не сможете уследить. Различные вещи вроде умных указателей/ссылок как в VB6 намного упрощают данную задачу поскольку компилятор сам следит за жизнью объектов, а запрет на прямое манипулирование памятью защищает данные.

0

Сообщение от The trick Не бывает такого что программист или команда сделали сразу сложную программу без ошибок.

В идеале когда работа идёт на качество, а не на дедлайн - так и должно быть. Как раз за это всегда и выступал,
чтобы люди всё разрабатывали и тщательно обдумывали в документации и уже потом спокойно перебивали в код
100% формализованные решения с полностью просчитанными зависимостями, либо последовательно отсекали их.
Для этого и существует, модульность и декомпозиция. Багом называю не невнимательность программиста,
а недочёт в аналитике задачи. Если первое человек видит, исправляет и он чист, то второе это реальный косяк.

Давно в миру пытаются пропихнуть такие вещи как "быстрая разработка", когда сначала разрабатываешь
какой-то чёрти пойми как работающий костыль, а потом уже дико бешено начинаешь нашпиговывать его функционалом,
не взирая на то, рассчитана ли уже внедрённая архитектура на такие манипуляции. Это уже лажа концептуально.
В итоге обычно это заканчивается тем, что продукт на пути всего своего жизненного цикла содержит
баги(в т.ч критические) и их количество не уменьшается. Я о том, что это нифига не нормально кто бы
чего не говорил и чем бы не мотивировал. В реальности фраза "поспешишь - людей насмешишь" работает
всегда, причём безотказно.
Человеческий фактор решает существенно больше, чем какие-то резолюции. А для профи же по идее
разницы нет использовать указатели или нет, это новичёк может где-то там в bound контроле лохануться.
нормальный профи вообще всё тестирует всегда, ежели недоглядел. Модульная разработка тем
и хороша, возможностью оттестировать каждую функцию. К этому моменту в теории уже должно
всё работать, это просто формальность по контролю точности забитого в код механизма.

Сообщение от The trick решая задачу написания какого-нибудь парсера RTF/DOCX ты просто утонешь в куче разных кусочков, в которых тысячи зависимостей, и за каждой ты или команда просто не сможете уследить.

Для таких вещей нужно хорошо писать документацию. Грамотная документация значит очень много.
Какая бы толстая задача не была. Понятно что один человек всё не уследит, особенно если он пытается
уследить за тем, что разрабатывало не один десяток людей. С другой же стороны если уследить сложно
значит это знак, что не всё сделано концептуально хорошо.
У меня например по UI/UX полно идей как можно улучшить текущие концепции, многие текущие концепции
- это вообще полный слив. Считаю нужно критически подходить ко всему, что "гуляет" в IT.

0

Сообщение от Quiet Snow В идеале когда работа идёт на качество, а не на дедлайн - так и должно быть.

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

Сообщение от Quiet Snow Человеческий фактор решает существенно больше, чем какие-то резолюции. А для профи же по идее разницы нет использовать указатели или нет, это новичёк может где-то там в bound контроле лохануться. нормальный профи вообще всё тестирует всегда, ежели недоглядел. Модульная разработка тем и хороша, возможностью оттестировать каждую функцию. К этому моменту в теории уже должно всё работать, это просто формальность по контролю точности забитого в код механизма.

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

Сообщение от Quiet Snow Для таких вещей нужно хорошо писать документацию. Грамотная документация значит очень много. Какая бы толстая задача не была. Понятно что один человек всё не уследит, особенно если он пытается уследить за тем, что разрабатывало не один десяток людей. С другой же стороны если уследить сложно значит это знак, что не всё сделано концептуально хорошо.

Документация чего? Формата? И как она поможет? Ты посмотри сколько дыр в том же офисе, там их латают и латают в течение многих лет. Хочешь сказать что офис написан бездарями?

0

Сообщение от The trick Хочешь сказать что офис написан бездарями?

Могу говорить только за себя. Для меня это работает железобетонно. Проги пишу не сложные, но ёмкие
и не каждый профи из нынешних даже так напишет, поставь его в такие же условия.

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

Документация чего? Формата? И как она поможет?

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

Сообщение от The trick Это в идеале. Назови мне хоть одного программиста кто может написать сложную систему без единого бага с первого раза. Такого не бывает.

Именно поэтому и написал про то, что считаю багом. Мой подход предполагает сборку программы
из уже оттестированных модулей. Я допускаю невнимательность программиста при переводе документации
в код, но не допускаю перевода сырых, необдуманных решений.
Уже называл хороших прогеров, locm и ты кстати в их числе. И баги у всех них были исключительно
из-за чужих уродских решений, например Стас когда писал свою шахматную оболочку заколебался
парсить нестандартные "высеры" готовых движков, он рассказывал что там вообще все движки выдавали
разные фокусы и под каждый приходилось хардкодить. Тогда ему помогал в тестировании.
Т.е. которые либо работают нестандартно, либо не имеют нормальной документации. А всё из-за банальной
вещи - отсутствия жёсткой стандартизации тех или иных вопросов. А стандартизация это в первую очередь
ограничительный документ.

Добавлено через 25 минут

Сообщение от The trick Ты все идеализируешь. Как ты описываешь так не бывает.

Не веду речь про науку с кучей недетерминировщины и про те случаи, когда нужно работать в дедлайн.
Если твоя программа от чего то зависит, она уже может быть с багами. Больше зависимостей,
больше вероятности их появления. Потому что ты не знаешь формализованы ли те задачи до конца
или нет, более того ты даже не знаешь сделаны ли они по твоей концепции безопасности, про это
тебе кстати намекнул locm.
Просто хочу сказать о том, что не стоит заранее метить багом то, что является лишь способом действия.
Эта концепция безопасности - лишь заслонка от совсем банальщины, это не гарант отсутствия багов
на который можно уповать. Базовые принципы ведения разработки каждому прогеру хорошо известны
их не обхитрить. А объёмы задачи это лишь ноша аналитика и программиста, если он к ней не готов - смысла
лезть туда не вижу. Никто как бы не говорил, что любое решение делается быстро и безболезненно.

0

Сообщение от Quiet Snow Могу говорить только за себя. Для меня это работает железобетонно. Проги пишу не сложные, но ёмкие и не каждый профи из нынешних даже так напишет, поставь его в такие же условия.

Уверен что в твоих программах нет багов? Скинь пару емких примеров.

Сообщение от Quiet Snow 2003-й офис был офигенно написан, как сейчас дела обстоят не знаю, видел новые, от их уродского новоиспечённого интерфейса для лохов можно проблеваться. От супер продуманного эргономичного интерфейса было принято решение отказаться в сторону какой-то дичи.

https://www.cvedetails.com/vul... -2003.html

Сообщение от Quiet Snow Формата, структуры данных программы и схематика всех механизмов. Плюс полная логич. формализация, что в переводе на русский означает - меньшим числом шагов сделать отдельный конкретный механизм уже нельзя, т.к. его логика полностью проанализирована и меньшего по детализации уровня там просто не существует.

Но это не поможет избежать всех багов. На практике чтобы уменьшить количество багов нужно тестировать и лучше каким-нибудь специально разработанным фаззером.

Сообщение от Quiet Snow Именно поэтому и написал про то, что считаю багом. Мой подход предполагает сборку программы из уже оттестированных модулей. Я допускаю невнимательность программиста при переводе документации в код, но не допускаю перевода сырых, необдуманных решений. Уже называл хороших прогеров, locm и ты кстати в их числе. И баги у всех них были исключительно из-за чужих уродских решений, например Стас когда писал свою шахматную оболочку заколебался парсить нестандартные "высеры" готовых движков, он рассказывал что там вообще все движки выдавали разные фокусы и под каждый приходилось хардкодить. Тогда ему помогал в тестировании. Т.е. которые либо работают нестандартно, либо не имеют нормальной документации. А всё из-за банальной вещи - отсутствия жёсткой стандартизации тех или иных вопросов. А стандартизация это в первую очередь ограничительный документ.

Как раз использование концепции ЯП это и есть сбор проекта из оттестированных модулей. Не нужно (если специально не оговорено) лезть в сырую память, а нужно использовать средства языка. Ну согласись, глупо вместо массивов к примеру выделять память через LocalAlloc и освобождать через LocalFree, контролировать доступ за пределы когда есть более безопасные массивы которые делают это автоматом. Тоже самое с указателями. Проще и безопаснее иметь умную ссылку и не заботится что где-то что-то ты освободил/не освободил чем вручную все тоже самое реализовывать и следить за этим. Заметь я не против всех этих низкоуровневых штук как указатели и сырая память, я просто говорю что это небезопасно и по возможности нужно пользоваться более высокоуровневыми и безопасными вещами.

0

Сообщение от The trick Ты все идеализируешь. Как ты описываешь так не бывает. К примеру записи за пределы буферов могут себя вообще не проявлять на тестах до поры до времени.

Для этого в ЯП должны быть средства поиска, типа такого. Быстрый старт в изучении C++ для относительно опытных программистов Basic
Как раз следит за наличием записи за пределами буфера. Причем следит не только за памятью, но и за глобальными и локальными переменными включая строковые. В большинстве случаев находит проблему на этапе отладки.

Сообщение от The trick Хочешь сказать что офис написан бездарями?

А что же они не используют предлагаемую вами концепцию безопасного программирования?

0

Сообщение от Quiet Snow Если твоя программа от чего то зависит, она уже может быть с багами. Больше зависимостей, больше вероятности их появления.

Я не пойму про какие именно ты баги говоришь? Я говорю о багах возникающих из-за нарушения концепции безопасного программирования. Я не говорю о логических багах в программе которые могут возникнуть из-за неправильной архитектуры. Логические баги - это другая тема. Логический баг с использованием концепции безопасного программирования почти никогда не приведет к тем ошибкам которые могут быть допущены с нарушением этой концепции. Я не говорю о том когда сам инструмент (зависимость) сама имеет какой-то баг в следствии того что она была написана с нарушением концепции и не была протестирована должным образом. Логический баг в общем случае закончит твою программу детерменировано и никакие данные не будут испорчены/скомпроментированы.

Сообщение от Quiet Snow Потому что ты не знаешь формализованы ли те задачи до конца или нет, более того ты даже не знаешь сделаны ли они по твоей концепции безопасности, про это тебе кстати намекнул locm.

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

Сообщение от Quiet Snow Просто хочу сказать о том, что не стоит заранее метить багом то, что является лишь способом действия. Эта концепция безопасности - лишь заслонка от совсем банальщины, это не гарант отсутствия багов на который можно уповать. Базовые принципы ведения разработки каждому прогеру хорошо известны их не обхитрить. А объёмы задачи это лишь ноша аналитика и программиста, если он к ней не готов - смысла лезть туда не вижу. Никто как бы не говорил, что любое решение делается быстро и безболезненно.

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

0

Сообщение от The trick Ну согласись, глупо вместо массивов к примеру выделять память через LocalAlloc и освобождать через LocalFree, контролировать доступ за пределы когда есть более безопасные массивы которые делают это автоматом.

Допустим ситуацию что WinAPI функция требует указатель. Вы вместо выделения памяти создали массив требуемого размера и передали указатель функции, но допустили ошибку (люди иногда ошибаются) и в массиве выделено меньше памяти чем нужно. VB автоматом сможет отследить такую ситуацию?
Вот к примеру вот всех этих кодах включенный purifier обнаружит запись за пределами выделенной памяти.

0

Сообщение от locm Для этого в ЯП должны быть средства поиска, типа такого. Быстрый старт в изучении C++ для относительно опытных программистов Basic Как раз следит за наличием записи за пределами буфера. Причем следит не только за памятью, но и за глобальными и локальными переменными включая строковые. В большинстве случаев находит проблему на этапе отладки.

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

Сообщение от locm А что же они не используют предлагаемую вами концепцию безопасного программирования?

Потому что это не всегда возможно, и баги как раз выходят в тех местах где эта концепция нарушается, а не наоборот. К примеру винда написана во многом на C, в котором нет средств предоставляющих какие-либо механизмы для этого. Чтобы переписать все с нуля нужно много сил/времени/денег, поэтому никто этим не занимается. Поэтому обычно если смотреть какую-либо уязвимость то она часто тянется еще с "бородатых времен" когда код писался таким образом как предлагаешь ты.

0

Сообщение от locm Как раз следит за наличием записи за пределами буфера. Причем следит не только за памятью, но и за глобальными и локальными переменными включая строковые. В большинстве случаев находит проблему на этапе отладки.

Каким боком тут вообще PureBasic влез?
Мы вроде как тут обсуждаем C++ в плане его полезности изучения относительно VB6? Не стоит задача изучать PureBasic, тем более он вообще ни к VB6, ни к C++ даже близко.
У него свои инструменты, свой синтаксис, свои возможности. Какой смысл тут приводить аргументы, ссылаясь именно на него?

Давайте про С++ c примерами, с его отладчиками и прочими плюшками, и как эти плюшки помогут в изучении VB6.

А то настрочили 10 страниц оффтопа, по делу вообще ни чего.
ИЛИ давайте ветку перекинем в священные войны, там и бейтесь со своим PureBasic vs VB6!

0

Сообщение от The trick Логический баг с использованием концепции безопасного программирования почти никогда не приведет к тем ошибкам которые могут быть допущены с нарушением этой концепции.

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

Сообщение от The trick Логический баг в общем случае закончит твою программу детерменировано и никакие данные не будут испорчены/скомпроментированы.

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

Сообщение от The trick locm не понял что я имел в виду, поскольку предоставляя задачу на замену указателям он сразу же начал нарушать концепцию.

Я писал что речь идет о работе с WinAPI и других случаях когда нужна работа с указателями.

Сообщение от The trick Я уже скинул что ничего эти средства не находят

У других находят, а у вас нет... Примеры выше запускали?

Сообщение от The trick более того я могу записать что-то и в буфер, но программа ожидает увидеть что-то другое там

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

Сообщение от Pro_grammer PureBasic, тем более он вообще ни к VB6, ни к C++ даже близко.

Работа с памятью похожа.

0

Сообщение от The trick Скинь пару емких примеров.

Редактор уже кидал. Крит багов там точно нет. Он тестировался на XP на нескольких машинах.
Хочешь качай тестируй:
https://docs.google.com/docume... BqNoc/edit
Реальная прога, требования к которой по UI были строго заданы проф аналитиком по UI, человек
разложил тогда всё вплоть до каждого клика мышкой. На этом редакторе он примерно 30 карт сделал.
Покажи мне человека из d2k комьюнити, кто создал столько же карт(нормальных, а не квадратных) в одно лицо.
Под 7 тоже работает, к сожалению в ~10 раз медленнее, хотя даже так вполне позволяет его
использовать с приемлемыми по юзабилити характеристиками. О чём уже писал ребятам с pb.
Это был слив железа от Microsoft и NVidia, каждый вендор подосрал.
Косяк не мой(на семёрку не метил, но был неприятно удивлён такой лажей), к сожалению такова
цена использования "чужих" технологий. Разработка была лишком объёмная, чтобы её перефигачить
под OpenGL. Сейчас мне нет резона этим заниматься. Возможно потом перебью, исходники остались.
На XP работает идеально, просто конфетка.

Сообщение от The trick https://www.cvedetails.com/vulnerabi...fice-2003.html

По твоей же ссылке, посмотри сколько в других:
https://www.cvedetails.com/pro... ndor_id=26

А они ведь по супер безопасной наверное написаны концепции. То что там после 2007-го то...

Сообщение от The trick Ну согласись, глупо вместо массивов к примеру выделять память через LocalAlloc и освобождать через LocalFree, контролировать доступ за пределы когда есть более безопасные массивы которые делают это автоматом.

Дело не в массивах, списках и прочих супер удобных и приятных штуках ЯП.
Для меня массив равен по безопасности голым указателям, просто потому что нет резона перебивать
туда неформализованное решение, моя прога не полезет гулять по памяти. Для меня это не вопрос
тестирования, мол только на него полагаюсь, нет, для меня это формальность, когда проверяю как работает
забитый механизм, неточность если она есть обычно всплывает сразу, потому что на этом внимание
и акцентировано(вывести необх параметры и отследить идентичность того, что на бумаге и что в коде).
Обычно есть тест кейсы, которые позволяют выявить косяк, прогер обязан их искусственно создать.

Добавлено через 27 минут

Сообщение от The trick Я не пойму про какие именно ты баги говоришь?

Ты привёл в пример баг отсутствия контроля границ.
Если напишу алгоритм корректно, корректно забью его в код, выход за границы меня не ожидает.
Так? Так какие ко мне тогда вопросы?

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

Концепция безопасности не гарантирует корректности алгоритмов, она просто принуждает
программиста использовать более высокоуровневые элементы. Но программисты обычно и так
сначала делают на ВУ, а потом уже лезут в дебри если надо быстрее. Более предусмотрительные
сразу понимают надо им оно или нет, чтобы не кодить по 10 раз, а сразу сделать хорошо.
Это вопрос выбора, это не гарант чего-то лучшего и более корректного. Если алгоритм написан
корректно, если он полностью формализован и корректно забит в код - он будет с равной
степенью безопасен, это человеческий фактор, но он так и так будет, его никуда не денешь.

0

Сообщение от locm Работа с памятью похожа.

Различие в средствах контроля, отлова возможных ошибок, уборке мусора и т.п.
Или в MSDN внезапно стали печатать примеры на PureBasic?
Давайте не отходить от темы, и прекращаем мерятся крутостью ЯП (тем более, это заслуга их авторов). Иначе тема уедет в https://www.cyberforum.ru/holywars/

0

Сообщение от locm Допустим ситуацию что WinAPI функция требует указатель. Вы вместо выделения памяти создали массив требуемого размера и передали указатель функции, но допустили ошибку (люди иногда ошибаются) и в массиве выделено меньше памяти чем нужно.

Я уже написал ведь - вызов WinAPI небезопасен. Ну спроектировали его таким еще очень давно, а изменять не могут в угоду обратной совместимости. Безопасные API обычно принимают либо какой-либо объект буфер, либо безопасный тип буферов типа BSTR или SAFEARRAY.

Сообщение от locm Вот к примеру вот всех этих кодах включенный purifier обнаружит запись за пределами выделенной памяти.

Не обнаружит:
Он насколько я понял проверят просто 4-байтовую сигнатуру (BADF00D) за буфером и все. Никто не мешает записать эту сигнатуру в буфер либо просто пропустить запись в эту область:

Сообщение от locm VB автоматом сможет отследить такую ситуацию?

Придерживаясь концепции безопасного программирования такой ситуации в принципе быть не может.

Вложения

vnrl_pb.zip (561 байт, 0 просмотров)

0

Сообщение от locm Одно дело если программа падает. Тогда можно с большой долей вероятности отладчик укажет где именно и совсем другое если "безопасное программирование" сгладило баг не дав проге упасть, но при этом исказив работу программы что может привести к куда более серьезным последствиям и отследить баг может быть сложнее.

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

Сообщение от locm Он может исказить вычисления что может испортить данные.

Какие? Приведи пример.

Сообщение от locm Я писал что речь идет о работе с WinAPI и других случаях когда нужна работа с указателями.

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

Сообщение от locm У других находят, а у вас нет... Примеры выше запускали?

Ты приводишь "удобные" для тебя примеры. Я тебе привожу примеры где это не работает. Мои примеры смотрел? Почему там не работает? Думаешь твои проги будут работать только в условиях "удобных" твоей программе?

Сообщение от locm Тогда я могу записать в переменную или массив что-то другое, а не то что программа ожидает там увидеть. Как ваше безопасное программирование поможет программе при этом функционировать правильно и выдать нужный результат?

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

Добавлено через 12 минут

Сообщение от Quiet Snow Редактор уже кидал. Крит багов там точно нет. Он тестировался на XP на нескольких машинах. Хочешь качай тестируй:

Посмотрю.

Сообщение от Quiet Snow А они ведь по супер безопасной наверное написаны концепции. То что там после 2007-го то...

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

Сообщение от Quiet Snow Дело не в массивах, списках и прочих супер удобных и приятных штуках ЯП.

Как раз в них.

Сообщение от Quiet Snow Ты привёл в пример баг отсутствия контроля границ. Если напишу алгоритм корректно, корректно забью его в код, выход за границы меня не ожидает. Так? Так какие ко мне тогда вопросы?

Да никаких. Ты посмотри что я писал, а то наверное вы думаете что я против всех этих низкоуровневых штук? Я вообще-то писал о концепции, что придерживаясь ее почти невозможно выстрелить себе в ногу. Но это же не говорит что сырой доступ к памяти - зло. Мало-того средства ЯП которые обеспечивают такой функционал работают на этом уровне. Другой момент что почти любую задачу такого небезопасного уровня можно переписать в безопасной манере, о чем я и написал.

Сообщение от Quiet Snow Концепция безопасности не гарантирует корректности алгоритмов, она просто принуждает программиста использовать более высокоуровневые элементы. Но программисты обычно и так сначала делают на ВУ, а потом уже лезут в дебри если надо быстрее. Более предусмотрительные сразу понимают надо им оно или нет, чтобы не кодить по 10 раз, а сразу сделать хорошо. Это вопрос выбора, это не гарант чего-то лучшего и более корректного. Если алгоритм написан корректно, если он полностью формализован и корректно забит в код - он будет с равной степенью безопасен, это человеческий фактор, но он так и так будет, его никуда не денешь.

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

0

Сообщение от The trick а через высокоуровневую прослойку которая делает проще разработку и позволяет обойти проблемы с безопасностью.

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

Сообщение от The trick ты абстрагируешься от железа чтобы тебе было проще

В большинстве случаев да. Просто разделяю логику НУ\ВУ, что-то делать бывает проще тупо на асме.
А что-то логичнее просто указателями голыми. Что-то разумеется массивами и т.п..
Для меня важна сопоставляемость(сходность) с самой идеей алгоритма.

Сообщение от The trick Ты же не пишешь всю программу на ассемблере

Да я опупею, разумеется нет

0

Сообщение от Quiet Snow Под 7 тоже работает, к сожалению в ~10 раз медленнее, хотя даже так вполне позволяет его использовать с приемлемыми по юзабилити характеристиками.

Не сумел оценить тормоза на 7-ке, при первом же запуске с картой ORD10.SCN


С другими картами то же...
На XP уже не могу запустить, дома нет такой.

0

Сообщение от Quiet Snow более менее нормальные программисты этим не страдают.

Ну вон сколько примеров уязвимостей я скинул, это только в одной линейке продуктов.

Сообщение от Quiet Snow Но и сути то оно не меняет, если злоумышленник поимеет доступ к бинарнику, он чё хочешь перефигачит и указатель и функцию свою пропишет.

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

0

...

Вложения

8play7.zip (15.8 Кб, 2 просмотров)

0

Сообщение от The trick Не обнаружит

Вы умышлено изменили условия.
Задача была отследить запись за пределами буфера. Тот код что я выложил, это выполняет?

Сообщение от The trick Никто не мешает записать эту сигнатуру в буфер либо просто пропустить запись в эту область:

Зачем ломать систему защиты, тем более что это не так просто? Ведь проверка выполняется сразу после вызова WinAPI. Речь о защите а не о взломе систем защиты.

Сообщение от The trick Я уже написал ведь - вызов WinAPI небезопасен.

Допустим что VB задачу по другому решить не получится. Что будете делать? Отвечать необязательно. Я видел много вашего кода на VB где используется WinAPI. Видимо в этот момент про безопасное программирование не думаете.

Сообщение от The trick Как раз-таки наоборот. К примеру запись за пределы буфера не всегда может себя проявить.

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

Сообщение от The trick Какие? Приведи пример.

Зависит от кода.

Сообщение от The trick А почему ты не привел тогда пример работы с WinAPI с ссылками?

Что мешало вам его привести?

Сообщение от The trick Ты приводишь "удобные" для тебя примеры. Я тебе привожу примеры где это не работает.

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

Сообщение от The trick Мои примеры смотрел?

Приветите пример на VB с GetModuleFileName с обнаружением записи за пределами буфера.
Только не нужно писать что это небезопасно. Представьте что по другому задачу не решить.

Сообщение от The trick Я вообще-то писал о концепции, что придерживаясь ее почти невозможно выстрелить себе в ногу.

Утопия! За это приходится платить.
Почему думаете современные приложения тормознутые и раздутые?

Сообщение от The trick Другой момент что почти любую задачу такого небезопасного уровня можно переписать в безопасной манере, о чем я и написал.

В VB или в управляемом коде?
Повторюсь не все возможно сделать на этом уровне. Мне часто приходится работать на низком уровне для взаимодействия с микроконтроллерами и на этом уровне управляемый код не самое лучшее решение.

0