C *

Раньше всё было лучше: компьютеры были большими, а буквы на экране — зелёными. Тогда они ещё назывались ЭВМ, а инженеры ходили по машинному залу в белых халатах. В те благословенные времена никто не заморачивался на тему user friendly-интерфейсов, а просто требовали от пользователя подготовить колоду перфокарт в соответствии с определённым форматом. Подготовил неверно — сам виноват. Это кажется не очень удобным и вовсе не «интуитивно понятным», но данный спартанский подход позволял обсчитывать весьма серьёзные задачи вроде моделирования ядерных реакций или расчёт полётного задания для космических ракет. И всё это при ресурсах, на два-три порядка меньших, чем почти любой современный смартфон.

Шло время, и перфокарты с магнитными барабанами канули в лету, в угоду пользователю стали доминировать программы с развитым GUI. Это стало подаваться как технический прогресс и забота об удобстве пользователе. А всегда ли это хорошо? А всегда ли это удобнее обычного текстового конфигурационного файла? Что-нибудь такое удобно воспринимать?

Порой кажется, что на фронте борьбы с проблемой 2038 года наступило относительное затишье. Однако время идет, и тот день, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, наступит уже меньше чем через 21 год. Этот срок может показаться большим, однако сравнительно долгий жизненный цикл многих встраиваемых систем подразумевает, что некоторые из них, будучи введенными в строй в наше время, все еще будут работать, когда наступит критический момент. Арнд Бергманн — один из основных разработчиков, занимающихся этой проблемой. На конференции Linaro Connect 2017 он поделился новостями о текущем положении дел в этой области.

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

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

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

Начнём с самого главного элемента — класс сервера SServer:

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

В этой статье мы познакомимся с POSIX Threads для того, чтобы затем узнать как это все работает в Linux. Не заходя в дебри синхронизации и сигналов, рассмотрим основные элементы Pthreads. Итак, под капотом потоки.

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

→ Часть 0
→ Часть 1, общие оптимизации

В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.

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

Под катом представлена обобщенная эвристика к алгоритму A*, полезная именно в свете практической пригодности на больших графах при ограниченных ресурсах, например, на мобилке.

Подразумевается, что мы будем писать прошивку под «голое железо». В противном случае применение protothreads смысла не имеет, т.к. мультизадачность должна обеспечиваться средствами ОС. Подразумевается также, что нам необходимо реализовать несколько более-менее сложных алгоритмов, связанных с операциями ввода-вывода. Ну и, как всегда в микроконтроллерах, очевидные требования по экономии RAM и энергопотребления.

Хабра, привет!

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

Разговор о программировании под Linux медленно перешел к тому, что этот человек стал утверждать, что сложность системного программирования на самом деле сильно преувеличена. Что язык Си прост как спичка, собственно как и ядро Linux (с его слов).

У меня был с собой ноутбук с Linux, на котором присутствовал джентльменский набор утилит для разработки на языке Си (gcc, vim, make, valgrind, gdb). Я уже не помню, какую цель мы тогда перед собой поставили, но через пару минут мой оппонент оказался за этим ноутбуком, полностью готовый решать задачу.

И буквально на первых же строках он допустил серьезную ошибку при аллоцировании памяти под… строку.

char *str = (char *)malloc(sizeof(char) * strlen(buffer));

buffer — стековая переменная, в которую заносились данные с клавиатуры.

Я думаю, определенно найдутся люди, которые спросят: «Разве что-то тут может быть не так?».
Поверьте, может.

А что именно — читайте по катом.

Прошло 1 апреля. Часто первоапрельские шутки, выложенные в Интернете, продолжают свое шествие, и всплывают совершенно в неожиданное время. О такой шутке про язык Си и будет эта статья. В каждой шутке есть только доля шутки. Код из нее я взял на вооружение для беглого тестирования на знание языка Си.

Надо написать программу (с пояснениями), в которой будет работать следующая строка:

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

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

Сегодня я хотел бы вновь рассказать о некоторых патчах, принятых за последнее время в PostgreSQL (а также утилиту pg_filedump). Аналогичные статьи, опубликованные на Хабре ранее, набрали достаточно много плюсиков, что заставляет думать, что они представляют для кого-то интерес. Если вы пропустили предыдущие статьи, вот они — раз, два, три. Несмотря на то, что рассмотренные патчи были написаны мной, не стоит забывать о вкладе людей, которые их ревьювили и тестировали. Проделанная этими людьми работа зачастую оказывается больше и сложнее работы самого автора. Особо активное участие в разработке рассмотренных пачтей приняли Федор Сигаев, Robert Haas, Tom Lane, Дмитрий Иванов, Григорий Смолкин, Andres Freund, Анастасия Лубенникова и Tels.

Привет всем, не знаю зачем это надо, но может кому пригодится…

Дисклеймер: Я ни в коем случае не являюсь профессиональным Си программистом.

Что нам понадобится:

1. Любой компьютер на Linux, Ubuntu, Centos, MacOS… с доступом к порту 443 или 8443 из интернета.
2. Любой Си компилятор
3. Бибилиотеки openssl, libssl-dev («apt-get install openssl libssl-dev» в терминале, для Ubuntu)

Пришло время вновь проверить проект FreeBSD и продемонстрировать, что даже в таких серьезных и качественных проектах анализатор PVS-Studio легко находит ошибки. В этот раз я решил взглянуть на поиск ошибок с точки зрения обнаружения потенциальных уязвимостей. Анализатор PVS-Studio всегда умел выявлять дефекты, которые потенциально можно использовать для атаки. Но мы никогда не акцентировали на этом внимание и описывали ошибки как опечатки, последствия неудачного Copy-Paste и так далее, и не классифицировали их, например, согласно CWE. Сейчас очень популярно говорить и о безопасности, и об уязвимостях, поэтому попробую немного расширить ваше восприятие нашего анализатора. PVS-Studio — это не только поиск багов, но ещё и инструмент, повышающий безопасность кода.

«Code Monkey like Fritos
Code Monkey like Tab and Mountain Dew
Code Monkey very simple man
With big warm fuzzy secret heart:
Code Monkey like you
Code Monkey like you»

— Jonathan Coulton — Code Monkey

Я думаю, многим знакома эта шикарная песня Jonathan Coulton'а, и эта жизненная ситуация, когда «Rob say Code Monkey very diligent», но «his output stink» и «his code not 'functional' or 'elegant'».

Язык Си, подаривший нам столько полезного софта, потихоньку был вытеснен из десктопа и энтерпрайза такими высокоуровневыми гигантами как Java и C# и занял нишу системного программирования. И все бы хорошо, но системщики — очень отбитые своеобразные ребята. Задачи, которые порой возникают перед ними даже своей формулировкой способны вогнать в ужас простых смертных. Собственно говоря, так же, как и некоторые решения.

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

Идея написать статью (которая войдет в цикл статей для новичков, остро жаждущих создавать что-то на микроконтроллерах при почти нулевых знаниях в области программирования в принципе) пришла мне после того, как мне пришлось немного отвлечься от своих основных дел, чтобы помочь другу настроить рабочую среду для написания софта под его небольшой домашний проект на основе board-а с stm32f103 на борту. Я рассчитывал, что это займет около получаса, максимум час, но ноутбук друга был на Windows 10 x64, что для меня уже непривычно (сам работаю в Ubuntu). По итогу мы потратили практически 8 часов на настройку и создание простого проекта, борясь с многими не очевидными вещами.

Параллельно с этим мне пришлось подробно объяснять, какой элемент сборки для чего нужен, а так же, как эти элементы взаимодействуют между собой, поскольку друг до этого никогда ранее с микроконтроллерами не сталкивался (от слова «видел Arduino в магазине»).

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

Что gdb можно как-то улучшать на питоне, знает каждый, кто хоть раз заглядывал в документацию. А кто хоть раз просматривал ее по диагонали, знает про такую штуку, как «Pretty Printers» — которые вроде позволяют gdb красиво печатать разные сложные структуры. Я документацию по диагонали просматривал, хотя особо и не вникал. Но однажды, набирая в очередной раз что-то вроде (все примеры из исходников MariaDB, которые я дебажу по много раз каждый божий день, иногда исключая выходные):

(gdb) p/t table->read_set->bitmap[0] @ (table->read_set->n_bits+7)/8

Я подумал «а фигли?». И все заверте…

Введение

Ошибки, увы, неизбежны, поэтому их обработка занимает очень важное место в программировании. И если алгоритмические ошибки можно выявить и исправить во время написания и тестирования программы, то ошибок времени выполнения избежать нельзя в принципе. Сегодня мы рассмотрим функции стандартной библиотеки (C Standard Library) и POSIX, используемые в обработке ошибок.

Привет, Хабр! Спешим поделиться радостной новостью – мы выпустили первый в этом году релиз нашей кросс-платформенной IDE для C и C++, CLion 2017.1!



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

• Поддержка C++14 (всё кроме constexpr)
• Начальная поддержка C++17 (мы начали с самой востребованной возможности – nested namespaces)
• Возможность конвертировать тип переменной в auto
• Во время отладки программы, при отсутствии файлов с исходным кодом можно переходить на код на дизассемблере (disassembly view)
• Поддержка фреймворка для юнит-тестирования Catch
• Значительное ускорение отклика редактора при печати кода (Zero Latency Typing)
• И, наконец, экспериментальная поддержка компилятора Microsoft Visual C++!

И это еще не все! Читайте подробности ниже.

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

Привет, я все еще Марко и все еще системный программист в Badoo. На прошлой неделе я опубликовал перевод о PIC в шареных библиотеках, но есть вторая часть – про разделяемые библиотеки на х64, поэтому решил не оставлять дело незаконченным.

С версии 1.5 компилятор Go поддерживает несколько режимов сборки, определяемых флагом buildmode. Их ещё называют режимами исполнения Go (Go Execution Modes). С их помощью go tool может компилировать пакеты Go в нескольких форматах, включая архивы и библиотеки общего пользования Go (shared libraries), архивы и библиотеки общего пользования Си, а с версии 1.8 — и динамические плагины Go.

В статье мы рассмотрим компилирование пакетов Go в библиотеки Си. В этом режиме сборки компилятор генерирует стандартный бинарный файл объекта (shared object) (.so), передавая функции Go в качестве API в стиле Си. Мы поговорим о том, как создавать библиотеки Go, которые можно вызывать из C, Python, Ruby, Node и Java.

Весь код доступен на GitHub.