Если бы язык С был оружием

От автора: Наброски для этой статьи появились еще в начале 2015 года, правда, до публикации материалов дело так и не дошло. Наконец, решив, что в ящике моего письменного стола от вышеупомянутого «черновика» не будет никакой пользы, представляю его вашему вниманию в исходном виде. Единственное, что изменилось в тексте – год, с 2015 на 2016.

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

Итак, статья ...

Первое правило программирования на С – не используйте его, если можно обойтись другими инструментами.

Когда найти альтернативный метод не удается, самое время вспомнить о современных заповедях программиста.

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

На Хабре уже было пару статей о чипе ESP8266 китайской компании Espressif. Статья №1 и Статья №2. Не так давно я получил плату ESP-01 для проведения тестирования. Кому интересно, прошу под кат.

Open Source проекты с каждым днём набирают всё большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растёт. Всё это даёт огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.

Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «контрибьютинга», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.

Всем начинающим «контрибьютерам», которые столкнулись с похожим проблемами, добро пожаловать под кат.

Прим. переводчика: Это перевод статьи Питера Брайта (Peter Bright) «How security flaws work: The buffer overflow» о том, как работает переполнение буфера и как развивались уязвимости и методы защиты.

Беря своё начало с Червя Морриса (Morris Worm) 1988 года, эта проблема поразила всех, и Linux, и Windows.



Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь — Червь Морриса 1988 года — использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов.

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

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

После прочтения статьи Самая опасная функция в мире С/С++ я счёл полезным углубиться во зло, таящееся в тёмном погребе memset, и написать дополнение, чтобы шире раскрыть суть проблемы.

Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

В связи с этим я решил опробовать себя в роли рассказчика и затронуть техническую сторону Bitbucket. Прошу не рассматривать моё намерение как попытку рекламы, ибо я совершенно не преследую эту цель. Если эта статья обнаружит интерес со стороны читателей, я буду рад развивать тему и постараюсь ответить на возникающие вопросы.

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.

Данный отчет является логическим продолжением исследования «#root via SMS», завершенного в 2014 году командой SCADA Strangelove. Исследование затрагивало уязвимости модемов лишь частично, в рамках более широкого описания уязвимостей оборудования телеком-операторов. В настоящем документе представлено описание всех найденных и использованных уязвимостей в 8 популярных моделях 3G- и 4G-модемов, доступных в России и по всему миру. Найденные уязвимости позволяют проводить удаленное выполнение кода в веб-сценариях (RCE), произвольную модификацию прошивки, межсайтовую подделку запросов (CSRF) и межсайтовое выполнение сценариев (XSS).

В исследовании также описан наиболее полный набор векторов атак на клиентов телекома, использующих данные модемы — это может быть идентификация устройств, внедрение кода, заражение пользовательского компьютера, к которому подключен модем, подделка SIM-карты и перехват данных, определение местоположения абонента и доступ к его личному кабинету на портале оператора, а также целевые атаки (APT). Слайды презентации данного исследования с ZeroNights 2015 представлены здесь.

Картинка для привлечения внимания

Успокоившись после шока из-за того, что моя первая игра не взорвала интернет, я решил сделать еще одну. Первая мысль, с которой началась разработка второй игры, возникла в голове и без обдумывания стала краеугольным камнем в фундаменте игры: «если игра с бесконечным геймплеем не стала популярной, то нужно делать контенто-зависимую игру с уровнями».

Так как небольшой опыт создания игры у меня уже был, я вооружился не клавиатурой, как в прошлый раз, а карандашом и бумагой, и принялся «придумывать» игру. На разных листах А4 я записывал свои мысли по разным направлениям: игровые механики, сеттинг, интерфейс, правила, интересные мысли, запомнившиеся игры из детства и т. п.; при этом я параллельно шерстил Google Play Market в поисках вдохновения. В итоге, спустя несколько дней, было принято решение, что игра станет головоломкой, а именно — пазлом. За это время мой мозг и пальцы заскучали по программированию, в результате чего захотелось сделать хоть какой-нибудь прототип игры. Это сподвигло меня на более интенсивную проработку идеи пазла, и в итоге в качестве рабочего был принят вариант со следующими правилами: игровое поле состоит из квадратных кусочков пазла (далее они будут называться тайлами), на которых располагаются разноцветные линии; тайлы можно менять местами; цель игры: собрать пазл единственным образом, в котором линии одного цвета замкнуты в некий узор.

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

Идея

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

Вывод

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

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

В 2009 году Винсенту ДеВита, бывшему директору Национального института онкологии США и профессору медицины в Онкологическом центре на факультете медицины Йельского университета, поставили диагноз: рак простаты. Обычно при этом заболевании назначают гормональную терапию, но де-Вита повезло — его коллеги провели ему операцию, которая выходит за рамки стандартного лечения, и это спасло ему жизнь.

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

По мнению ДеВита, фраза «Нам не удаётся победить рак» говорит не о том, что человечеству не хватает для этого знаний, а о том, что бюрократия не позволяет им воспользоваться достижениями науки.

Сделать себе внешний аккумулятор для ноутбука я хотел уже давно, 3-4 года назад для работы в парке. Хоть и мечта рисовать схемы и трассировать платы в парке Горького или Битцевском лесу так и не реализовались (пока), но внешний аккумулятор (назовем его по-современному — PowerBank) я таки сделал. О том как это устройство проходило путь от макета до конечного изделия и почему я делал то, что уже есть на рынке, под катом.

Несколько месяцев назад на хабре появилась статья «Реализация многоуровневого меню для Arduino с дисплеем». «Но, погодите, — подумал я. — Я написал такое меню еще шесть лет назад»!

В далеком 2009 году, я написал первый проект на базе микроконтроллера и дисплея под названием «Автомат управления освещением», для которого потребовалось создать такую оболочку меню, в которую влезет тысяча конфигов, а то и более. Проект был успешно рожден, компилируется и способен работать до сих пор, а оболочка менюОС пошла кочевать из проекта в проект, используя лучшие практики Ущербно-Ориентированного программирования. «Хватит это терпеть» сказал я, и переписал код.

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

Введение

Всем привет! После завершения цикла по датчикам были вопросы различного плана по измерению параметров потребления бытовых и не очень электроприборов. Кто сколько потребляет, как что подключать чтобы измерить, какие бывают тонкости и так далее. Пришло время раскрыть все карты в этой области.
В этом цикле статей мы рассмотрим тему измерения параметров электроэнергии. Этих параметров на самом деле очень даже большое количество, о которых я постараюсь постепенно рассказать небольшими сериями.
Пока в планах три серии:

• Измерение электроэнергии.
• Качество электроэнергии.
• Устройства измерения параметров электроэнергии.

В процессе разбора будем решать те или иные практические задачи на микроконтроллерах до достижения результата. Разумеется, большая часть данного цикла будет посвящена измерению переменного напряжения и может пригодиться всем любителям контролировать электроприборы своего умного дома.
По итогам всего цикла мы изготовим некий умный электросчетчик с выходом в интернет. Совсем отъявленные любители контролировать электроприборы своего умного дома могут оказать посильную помощь в реализации коммуникационной части на базе, например MajorDomo. Сделаем OpenSource умный дом лучше, так сказать.
В этой серии в двух частях мы разберем следующие вопросы:

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

Подкатом вы найдете ответы на первые два вопроса данного списка. Я намеренно не затрагиваю вопросы точности измерения показателей и с данной серии лишь радуюсь полученным результатам с точностью плюс-минус лапоть. Этому вопросу я обязательно посвящу отдельную статью в третьей серии.

Вступление: я был озадачен.

Несколько лет назад, после более чем 25 лет работы с этими вещами, я узнал кое-что новое о керамических конденсаторах. Работая над драйвером светодиодной лампы я обнаружил, что постоянная времени RC-цепочки в моей схеме не сильно смахивает на расчётную.

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

Я проверял схему в её естественной среде: в корпусе, который в свою очередь сам по себе был зачехлён чтобы имитировать кожух потолочного светильника. Температура компонентов в некоторых местах достигала более чем 100ºC. Для уверенности, и чтобы освежить память я перечитал даташит на используемые конденсаторы. Так началось моё переосмысление керамических конденсаторов.

Объявлено новое соревнование 7400, и нужно сделать что-то новое. Нельзя ударить в грязь лицом после победы в прошлом году ;)

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

Я устроил мозговой штурм с моими товарищами: Педерсеном (Pedersen), Асбьёрном (Asbjørn) и Флеммингом (Flemming), которые тут же придумали множество смешных идей. И вот Флемминг упомянул RFID (он разработчик системы управления доступом, которая основана на RFID). А вот это уже мысль. Конечно, первые мысли были об RFID-считывателе, но мы уже собрали их довольно много, и это было скучно. Однако, появилась идея сделать RFID-метку. Я не знаю, кто упомянул это первым, и, как обычно в мозговом штурме, идеи рождаются коллективным разумом. Итак, решено сделать RFID-метку, собранную исключительно на 7400-ой логике.

Если в одном из моих прошлых постов речь шла о довольно современном подходе к построению сбалансированных деревьев поиска, то этот пост посвящен реализации АВЛ-деревьев — наверное, самого первого вида сбалансированных двоичных деревьев поиска, придуманных еще в 1962 году нашими (тогда советскими) учеными Адельсон-Вельским и Ландисом. В сети можно найти много реализаций АВЛ-деревьев (например, тут), но все, что лично я видел, не внушает особенного оптимизма, особенно, если пытаешься разобраться во всем с нуля. Везде утверждается, что АВЛ-деревья проще красно-черных деревьев, но глядя на прилагаемый к этому код, начинаешь сомневаться в данном утверждении. Собственно, желание объяснить на пальцах, как устроены АВЛ-деревья, и послужило мотивацией к написанию данного поста. Изложение иллюстрируется кодом на С++.

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

Процессоры, используемые в наших продуктах — это, в основном, 16- и 32-битные микроконтроллеры Microchip, имеющие RAM от 8 до 32 кБ, и ROM от 128 до 512 кБ, без MMU. Иногда, для самых простых устройств, используются еще более скромные 8-битные чипы.

Очевидно, что у нас нет (разумных) шансов использовать ядро Linux. Так что нам нужна какая-нибудь RTOS (Real-Time Operating System). Находятся даже люди, которые не используют никаких ОС в микроконтроллерах, но я не считаю это хорошей практикой: если железо позволяет мне использовать ОС, я ее использую.

Несколько лет назад, когда мы переходили с 8-битников на более мощные 16-битные микроконтроллеры, мои коллеги, которые были гораздо более опытными, чем я, рекомендовали вытесняющюю RTOS TNKernel. Так что это — та ОС, которую я использовал в разных проектах в течение пары лет.

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

Этот пост попытка кратко оформить все, что я читал или слышал из разных источников про операторы приведения типов в языке C++. Информация ориентирована в основном на тех, кто изучает C++ относительно недолго и, как мне кажется, должна помочь понять cпецифику применения данных операторов. Старожилы и гуру С++ возможно помогут дополнить или скорректировать описанную мной картину. Всех интересующихся приглашаю под кат.