• Искусство написания простых и коротких функций
    0
    Здоровая простыня находится в одной единице трансляции, а куча маленьких файлов может быть разбросана по различным объектным файлам. С подобным может справиться ICC, но на больших проектах это приведет к взрывному росту времени компиляции.
  • Пасхалка в Mr Robot S02E01
    +2
    использование уязвимости bashdoor (shellshock) для получения файла /etc/passwd

    А что такого секретного в /etc/passwd?

    Также могу посоветовать использовать curl -L — он самостоятельно пройдет по редиректам.
  • Принят закон о налоге на Гугл
    +1
    Более насущный вопрос: попадает ли Steam под этот закон?
  • Под высокой нагрузкой: наши способы применения Tarantool
    +3
    >1. И зачастую многие кейсы написать на Lua проще чем на SQL
    SELECT… FROM a LEFT JOIN b on a.field = b.field ORDER BY… OFFSET x LIMIT y на SQL записывается очень просто. «DELETE FROM t WHERE secondary_nonuniq_key < y» или «UPDATE a SET field=field1+field2 WHERE non_uniq_key > x AND non_key_filed < y»— еще проще. Вы точно видели, _как_ это реализуется в тарантуле на lua? Приятного мало, очень много способов прострелить себе ногу.
    Не понимаю, почему в штатной поставке нет проверенных и оптимизированных разработчиками функций для выполнения таких задач.

    >3. оверхед будет зависеть от размера туплов. Копия базы хранится в памяти не будет
    Не совсем вас понял: от размера или от количества? Потому что если от размера tuples, то это выглядит как копирование (или там copy-on-write — скопируются только tuples, которые были изменены во время отправки запроса?). Меня сильно смущает, что iproto-пакет содержит длину — возникает ощущение, что данные предварительно сериализуются и копируются во временный буфер.

    >4. можете показать пример кода, чтобы было чуточку понятней?
    http://pastebin.com/b4Y5u3CW

    >5. Попробуйте 1.6.8. Там очень много доработок в аллокаторе.
    Честно говоря, нет желания заниматься бенчмарками, потому что перехода на 1.6 не будет без процедуры миграции данных.

    >6. 7.
    Хотелось бы увидеть ответы на эти вопросы — они не требуют ни бенчмарков, ни исследований (при условии, конечно, что в проекте есть разработчики, которые хорошо знают его внутренности — не сочтите за грубость).

    >8. Но по нашему опыту и опыту многих наших кастомеров
    Я, конечно, не кастомер (то есть, не платил деньги за саппорт), но вот вам «реальный кейс» (кстати, надеюсь, вы насладитесь краткостью конструкции join): http://pastebin.com/tYttKMdZ
    И прежде чем вы будете рекомендовать денормализацию, хочу заметить, что space0 => space1 и space1 => space2 — это many-to-one, причем «many» — это действительно много, и изменения в space2 должны быть сразу видимы в выборках.
    Кстати, было бы круто, если бы вы на данном конкретном примере поделились, как можно обойти space1 по HASH-индексу в условиях изменения данных. По TREE я и сам умею.

    >9. Мы работаем сейчас над миграцией.
    Знаете, если бы я был вашим клиентом с tarantool 1.5, для которого выходят только багфиксы в течение последнего года и вы порекомендовали мне перейти на 1.6, я был бы весьма недоволен таким ходом вещей.
  • Под высокой нагрузкой: наши способы применения Tarantool
    +18
    Такое ощущение, что статью писали копирайтеры на аутсорсе, настолько чудовищно много технических деталей замалчивается.

    >БД — это нечто надёжное, с транзакциями, серверным языком запросов.
    А как с «серверным языком запросов у tarantool»? Все еще нужно писать join-ы руками? Что делать, когда есть необходимость выбрать значительную часть dataset-а по нетривиальному условию? Писать server-side lua программу плюс клиентское приложения под последовательный вызов этой серверной функции?

    >Чтение файлов в память с магнитного диска происходит со скоростью 100 Мб/с. То есть, например, база данных в 100 Гб считается за 1000 с — примерно 15 мин.
    Правда время простоя будет существенно больше, потому что данные надо не только прочитать с диска, но и перестроить индексы. Иногда — много индексов. Будьте готовы к «холодному старту» за полчаса минимум. И если что-то произойдет и с репликой — добро пожаловать в получасовой downtime.

    И, раз уж вы говорите о больших объемах данных, можете ответить на пару вопросов:
    1) Что произойдет, если я сделаю «select *» из огромной базы? От чего будет зависеть дополнительный оверхед по памяти? От размера tuple-ов или от их количества? В какой момент эта дополнительная память будет освобождена: после полного вычитывания запроса клиентом или «по мере отправки»?
    2) Упаковка tuple-ов, выбранных из тарантула, в lua-шную таблицу делает дубликаты этих tuples?

    >У нас используется свой собственный аллокатор, типа Slab-аллокатора, позволяющий минимизировать влияние фрагментации памяти.
    Позвольте спросить, каким образом? Без переноса данных между slab-ами одного класса, при определенных паттернах нагрузки возникает забавная ситуация, когда heap состоит из огромного количества полупустых slab-ов «мелких» объектов, а на выделение более крупного объекта памяти уже не хватает. К сожалению, сталкивался лично в 1.5 при «разрастании» tuple-ов. «Лечил» рестартом.

    >Если вам нужно хранить 1 млрд строк, в каждой из которых десять полей, размер поля — четыре байта, то это будет 4 х 10 х 1 млрд плюс 1–10% оверхеда на управляющие структуры.
    Простите, но как же вторичные индексы? Мне вот, например, не хочется выяснять из кода, дублируются ли значения ключевых полей в индексы, или используется указатель на поле в tuple-е? Между прочим, очень животрепещущий вопрос, когда ключ занимает «значительную часть» tuple.

    И коль скоро речь зашла об индексах, есть ли способ обойти space с HASH-индексом по primary key в условиях изменения space-а? В РСУБД даже в таком случае «select *» предсказуемо себя ведет.

    Есть какие-то планы на использование многоядерности при обработке немодифицирующих запросов? При использовании «lua-join-ов» задекларированные «сотни тысяч запросов в секунду» очень быстро превращаются в «пару десятков тысяч», причем узким местом становится именно CPU, а не RAM, так что шардинг в таких условиях видится костылем, а не панацеей.

    Я правильно понимаю, что версия 1.5 теперь abandoned и миграция данных 1.5 => 1.6+ — моя головная боль? Запрос «tarantool migration guide» выводит на репозиторий сотрудника Mail.Ru с, кхм, не совсем очевидной инструкцией. Есть ли какие-то гарантии (понимаю, в контексте бесплатного open source продукта это звучит неуместно, но все же), что эта история не повторится в ближайшее время, когда в текущем формате сериализации обнаружится «фатальный недостаток»? Почему просто нельзя сделать в 1.6 reader снапшотов и xlog в формате 1.5? Набор примитивный операций из 1.5 навряд ли был «урезан» в 1.6.
  • Критические уязвимости в клиенте и серверной части Git позволяют осуществлять удаленное выполнение кода
    +21
    Какая-то чрезвычайно сомнительная уязвимость: возможность запихнуть путь длиной 2Gb уже само по себе может вызвать DoS, когда попытка выделить следующую пару гигабайт под пути закончится ENOMEM-ом.

    Вообще странная пошла мода вешать «критические» ярлыки на всякую минорщину: нет proof of concept эксплоита хотя бы без ASLR => о каком RCE речь?

    P. S. Кстати, в посте замалчивается важная деталь: теоретической возможности RCE нужно «всего лишь» каким-то чдом выставить executable-бит на страницах выделенной памяти, либо иметь W+X страницы с кодом. Даже при отключенном ASLR шансы выполнить что-то злоумышленнически-вразумительное навряд ли будут существенно больше нуля.
  • Свежий взгляд на код Oracle VM VirtualBox
    0
    >Когда такие люди допускают такие ошибки…
    Если бы был язык, в котором ошибки подобного рода были невозможны, все бы уже писали на нем.
  • Как непродуманные предупреждения компиляторов помогают портить совершенно правильный код
    +8
    Во-первых, все замечательно решается без шаблонов и предупреждений:
    if (filelength & ~(unsigned long)(size_t)-1) {
    /* error fillength is too large */
    }


    Во-вторых, считается хорошим тоном нужность подобных проверок определять в configure time (когда запускается cmake или иной аналог configure-скриптов), соответственно в итоге мы никогда не получим «condition always true» для совпадающих по размеру unsigned long и size_t.

    В-третьих, если почитать стандарт, то можно написать намного понятнее и также без предупреждений (gcc-4.8.5):
    #include <limits.h>

    if (filelength > SIZE_MAX) {
    /* file too large */
    }
  • Как сэкономить миллион долларов с помощью Tarantool
    0
    >Tarantool в пике делает 300К селектов на 1 ядре
    Это при каких условиях?
    На официальном сайте тарантула есть бенчмарк http://tarantool.org/benchmark.html, показывающий в районе 100k select-ов в секунду, а вы говорите о 300k.

    >На один физический сервер — умножайте на 24
    А память на 24 умножать не затратно будет?

    >Шардить по ядрам
    А потому ходить в шарды черед прокси (кстати, многопоточную или single-threaded?) и в итоге придем к тому, что «лучше бы вовсе не шардили».
    Кстати, availability (не говоря уже о запросах «посчитать что-то среди имеющихся данных) страдает от шабрдинга, т. к. возрастает вероятность недоступности одного из шардов. Плюс увеличивается время старта при использовании AVLTREE-индексов.
  • Почему расчет перцентилей работает не так как вы ожидаете?
    0
    Но задача мониторинга — привлечь внимание к проблемным ситуациям. Если p99 = 1000ms может быть проблемой, то лучше это честно нарисовать + дать возможность изменять масштаб времени. Тогда будет прекрасно видно, что за одним «проблемным пикселем» скрывалось несколько интервалов и более подробно проанализируем именно интервал с p99 = 1000ms.
  • Как сэкономить миллион долларов с помощью Tarantool
    0
    >По нашему опыту и тестам Тарантул быстрее HandlerSocket, причем в разы быстрее
    Вот здесь http://yoshinorimatsunobu.blogspot.ru/2010/10/using-mysql-as-nosql-story-for.html пишут о 750k select-ов по primary key в секунду. Честно говоря, я недоумеваю, каким образом однопоточный процесс может выиграть у многопоточного, когда в современных процессорах число логических ядер доходит до 24.
  • Как сэкономить миллион долларов с помощью Tarantool
    0
    Решаемо через хранимые процедуры на LUA (можно реализовать почти что любой сложный SQL-запрос — вопрос лишь в вашем терпении).
    Область применения у tarantool весьма специфичная, не предполагающая вот таких вот сложных use cases.
    Ни в коем случае не покупайтесь на сравнения с реляционными СУБД. В лучшем случае tarantool можно сравнить с HandlerSocket в MySQL, где в «терминах грубой силы» победит MySQL (за счет multicore), а по гибкости однозначно tarantool.
  • Почему расчет перцентилей работает не так как вы ожидаете?
    0
    С первого взгляда кажется логичным хранить точные значения персентилей с некоторым фиксированным значением (например с посекундным, т. е. p99 в течение секунды), а при построении графиков использовать max (или min по обстоятельствам) для вычисления y-координаты точки, в которую входит несколько интервалов.
    Мне видится только один недостаток: нужно заранее определиться, какие персентили храним и рисуем.
  • Как сэкономить миллион долларов с помощью Tarantool
    +1
    >А мы это у себя реализовали в своих собственных внутренних проксях, через которые мы из любого кода ходим в Тарантул.
    Что такого можно сделать во внешней проксе, чего нельзя сделать в коннекторе?

    >У нас есть уже в 1.6 асинхронная репликация мастер-мастер
    Дублирование запроса на соседа — это дублирование запросов на соседа. Репликация все-таки должна оставлять данные в консистентном состоянии.

    >В 1.7 у нас будет синхронный мастер-мастер на основе RAFT.
    Честно говоря, я не вполне понимаю вектор развития tarantool. То он позиционируется как «мемкеш на стеродидах», то как «lua application server». Судя по рекламе, которую вы даете в своих постах, это интересная наработка, которой мало кто пользуется, потому что не знают, как. Вы лучше определитесь с нишей, соберите набор best practices, дефолтные конфигурации для типовых задач, и т. д. Вот MySQL, сколько бы его ни ругали, используют повсеместно, потому что о нем полно информации.

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

    >Если же у вас нет лишней памяти на page cache под весь индекс или индекс целиком не влезает в память
    Я же писал, что можно параллельно cat'нуть индексный файл в /dev/null в некоторых случаях. И индекс всегда меньше данных. Взять, к примеру, базу постов хабра: реляционная база, хранящая только индексы по сообщениям и постам будет потреблять на это меньше памяти, чем tarantool, также хранящий в памяти тела сообщений.

    >Хранение в RAM будет более экономной, потому что не надо много реплик (одна машина тарантула тянет такую же нагрузку как десятки машин с традиционными базами)
    А можно с этого момента поподробнее? «Традиционные базы» могут использовать многоядерность современного железа и, как правило, успешно обрабатывают весьма нетривиальные запросы. Для простейших запросов по индексу у MySQL есть handlersocket, который в свое время позволял выжимать десятки тысяч запросов в секунду с одной железки. Более того, если база вдруг начинала «упираться в CPU», то можно было существенно все ускорить заменой железа: даешь больше ядер, получаешь лучшую производительность без каких-либо затрат на поддержку/разработку.
    Это, кстати, весьма актуальный вопрос, т. к. я не нашел бенчмарков с простенькими луашками, которые делают, скажем, простенький left join для результата из одной записи.
  • Как сэкономить миллион долларов с помощью Tarantool
    0
    А DELETE/UPDATE по вторичным индексам реализован в 1.6?
  • Как сэкономить миллион долларов с помощью Tarantool
    0
    >Если машина падает, то нагрузка автоматом уходит на реплику.
    Можно поподробнее с этого момента? Это встроенная возможность стандартного tarantool-коннектора, или вручную кодится в каждом клиенте? И если с SELECT-ами все понятно, то как быть с модифицирующими запросами в такой схеме? Как вы избегаете split brain-а при автоматических переключениях?

    >Но давайте вспомним про традиционные базы данных (MySQL/Postgress), они прогревают кэши хорошо если со скоростью 1-3Mb/s
    Откуда взята такая странная цифра? Традиционным базам нужно, чтобы индексы попали в page cache, что в некоторых случаях достижимо простым cat index.MYI > /dev/null на той же самой линейной скорости чтения.

    >50% downtime на протяжении часов
    Это как? Кроме того, разве в наше время такой downtime не решается установкой SSD для диска с данными? Будет ли хранение данных в RAM более экономным, чем использование SSD + «традиционная РСУБД»?
  • Как сэкономить миллион долларов с помощью Tarantool
    +1
    >у Tarantool есть режим hot standby, когда резервный сервер прямо на той же машине догоняется логами основного
    Ценой 2x по памяти?

    >Забудьте про JOIN в любой более-менее загруженном проекте
    Согласен. Но ведь в любом проекте рано или поздно наступает момент сбора и подсчета продуктовой статистики, где SQL начинает блистать, предоставляя возможность очень просто конструировать и выполнять сложные запросы с агрегатными функциями, join-ами, группировкой и прочими плюшками. В таких задачах хочется гибкости, а не писать руками join/avg и прочее на каждый чих.

    >В реальных задачах очень часто дешевле допустить некоторую избыточность, но при этом полностью избавиться от JOIN.
    Зависит от задач. Денормализация подразумевает дублирование данных, а дублирование, как правило, идет рука об руку с рассинхронизацией. И не надо забывать, что в РСУБД данные не хранятся в памяти и проблема JOIN-ов на самом деле лежит в области seek-ов по диску. Странно, что в тарантуле, где все хранится прямо в локальной оперативной памяти, могут быть какие-то проблемы с подобными запросами. Однако согласен, JOIN + WHERE + ORDER BY для результата на десятки тысяч строк ни к чему хорошему и в оперативной памяти не приведет.

    Что же касается планировщика и USING INDEX… Как правило, планировщик действительно лучше знает, какие индексы использовать в сложных запросах, USING INDEX был хорош в древние времена, дабы избегать filesort'ы. Очень странно, что проводя аналогию Tarantool — *SQL, вы замалчиваете, что любой запрос в тарантуле — это явный USING INDEX.

    >Скажу лишь что в Tarantool можно добавлять и удалять таблички и индексы на лету.
    А как выглядит добавление индекса на лету в однопоточном сервере?
  • Как сэкономить миллион долларов с помощью Tarantool
    +4
    Вы, конечно, очень радужно все описываете, однако какой как выглядит «холодный старт» тарантула? Я так понимаю, что ему необходимо прочитать с диска снапшот, затем проиграть «хвост» операций из журнала, затем перестроить индексы. И это все время полного простоя. Допустим, снапшот с нашими данными «весит» 80 гигабайт. Чтобы просто прочитать это с диска потребуется порядка 81920 / 200 ~ 409 секунд или почти 7 минут (200 mb/s вполне достойная скорость линейного чтения?). И это не какой-то «разогрев», когда «все тормозит». Это реальный 100%-й downtime.

    Кстати, насчет сохранения снапшота: правильно ли я понял, что по факту нужен двойной объем RAM? Я так понимаю, что используется fork + COW, но ведь это может стрельнуть в самый неожиданный момент.

    Да, а как быть со «сложными запросами», когда нужно использовать то один, то другой индекс, да еще дополнительно отфильтровывать результаты? Вы так настаиваете на сравнении с настоящими базами данных, что невольно хочется попросить предоставить кусок lua-процедуры, реализующий join в трех таблицах, где в where-условии также участвуют поля хотя бы из двух таблиц. Я представляю себе, как это выглядит, но не представляю человека, которому SELECT… FROM… JOIN… WHERE покажется сложнее, чем портянка аналогичного lua-кода.

    Ну и напоследок: что у вас делают, когда в многогигабайтной расшардированной базе появляется необходимость делать выборку по новому полю? Как добавить индекс без простоя?
  • Смешиваем цвета правильно или оптимизируем AlphaBlend
    0
    Рекомендую посмотреть в сторону intrinsic-ов: это почти прямое отражение mmx, sse и avx инструкций на «сишные функции». В итоге компилятор занимается подбором регистров, упорядочиванием и выравниванием команд, а программист говорит, что именно делать. В качестве бонуса получается некая «переносимость», т. к. intrinsics, в отличие от inline assembler'а, в различных компиляторах.
    У Intel есть замечательный гайд: https://software.intel.com/sites/landingpage/IntrinsicsGuide/
  • Используем официальный docker-образ NGINX в InfoboxCloud: часть 1
    0
    bash <(curl -s http://repository.sandbox.infoboxcloud.ru/scripts/docker/centos7/install.sh)
    Кхм…
    curl -s http://repository.sandbox.infoboxcloud.ru/scripts/docker/centos7/install.sh | bash -e
  • nxweb – HTTP сервер для приложений на Си
    0
    >Про timerfd и heap~ы не понял, можно развернуть мысль?
    Как правило, все таймеры можно объединить в heap (по-русски это вроде «пирамидой» называют). Однако, если таймерами управляет приложение, оно может объединить равноинтервальные таймеры в связанный список, привязанный к единственному элементу heap-а. В итоге rearm таймера будет иметь сложность O(1) вместо логарифмических вставки/удаления в heap. Именно поэтому я весьма скептически отношусь к помещению десятков тысяч таймеров в kqueue.

    >Меня вот напрягло что запись+чтение могут придти разом, и udata для них никак не разделяется, этот код я так и не отладил, оставив рабочим вариантом когда один описатель — один тип событий.
    Хранить в udata файловый дескриптор, а в userspace к файловому дескриптору привешивать цепочки watcher'ов, как это сделано в libev

    >Кстати, sendfile() в линухе тоже весь такой обрезанный: не умеет данные до/после файла из буферов посылать
    Но зачем? TCP_CORK + send/writev. Зачем плодить лишние сущности которые делают то же, что уже существующие? Цена syscall-а не такая высокая, как это многим кажется.
  • nxweb – HTTP сервер для приложений на Си
    0
    > Те превратить kqueue() в epoll() может любой дурак, тут ума совсем не надо.
    В современном ядре Linux epoll обладает практически всеми фичами kqueue (за исключением, пожалуй EVFILT_PROC). Конечно, иногда это происходит ценой написания большего количества кода, но результат получается весьма достойным.
    Кстати, использование timerfd для таймеров говорит о том, что не каждый дурак способен способен реализовать таймеры эффективно: в реальных приложениях, как правило, нужны таймеры, срабатывающие через равные промежутки времени, что можно сделать за O(1) в отличие от бездумного использования heap'ов для всего и вся.

    >но вот отдачи много: 2-16 мегабит в одно соединение. И куча таких вот соединение, «проксирование» IPTV потоков один-к-многим
    Я абсолютно не сведущ в FreeBSD-специфичных API, но как раз для этого в Linux завезли: a) splice (-30% cpu load при проксировании «один к одному») б) vmsplice (для отдачи кучи мегабит из одного соединения, для мультиплексирования) в) tee (для мультиплексирования «с трюкачествами»)
  • Tarantool 1.6 — давай начнем
    +1
    С некоторыми оговорками:
    — до тех пор, пока хватает производительности одного ядра
    — до тех пор, пока оперативной памяти хватает для хранения данных
    Ну и при сборке статистики нужно иметь в виду, что ввиду однопоточности сервера, обработка данных прямо внутри сервера будет блокировать его работу (придется время от времени звать box.fiber.sleep(0), что может привнекти некоторые нежелательные эффекты — до сих пор не уверен, что будет с итератором, ссылающимся на tuple, который был удалён во время такого вот sleep-а).
    Как по мне, статистику в тарантуле удобней агрегировать (можно еще WAL отключить), а работать с результатом все-таки удобнее в реляционной СУБД, где для join'ов не требуется программировать.
  • Вычислите длину окружности
    –1
    Забавно, что никто так и не вспомнил, что длина окружности — это 2*pi*r.
  • Анимация против лагов, или лучшая битва та, которой не было
    +4
    Offtop: однажды я выключил javascript в настройках браузера и поразился тому, насколько быстро стали отображаться все сайты. Мораль: поменьше анимаций, параллаксов и прочих рюшечек, назначение которых раздражать пользователя и затормаживать браузер.
  • Разыменовывание нулевого указателя приводит к неопределённому поведению
    –2
    Выше я приводил цитаты из стандарта языка C, где черным по белому написано, что в конструкциях &ptr->field и &*ptr никаких разыменований нет. И даже есть сноска, специально поясняющая, что &*(int*)NULL — это ок с точки зрения языка.

    В C++ есть нюансы, называемые «перегрузка операторов», где может встретиться вызов виртуальной функции, что требует валидного объекта для чтения vmt. Поэтому в плюсах &objptr->field действительно в общем случае UB. В C же отсутствие UB в таких случаях гарантировано стандартом.

    Большая ошибка полагать, что C — это как C++ (и делать на основании этого выводы), только без классов, оверлоадинга и перегрузки операторов. Это разные языки, но с похожим синтаксисом.
  • Разыменовывание нулевого указателя приводит к неопределённому поведению
    +2
    Я ни в коем случае не лезу в язык C++ — у него свой стандарт, гораздо более сложный и объемный. И я совершенно согласен, что в C++ для произвольного объекта выполнять «->» опасно, т. к. перегруженный оператор может вызывать виртуальные функции/обращаться к полям объекта, что приведет к «invalid behaviour».
    Однако я цитирую стандарт C и linux kernel, фрагмент кода которого приводится, написан на языке C, по стандарту которого UB нет.
    Хочу еще раз заметить, что все ваши рассуждения сводятся к «объект не может находится по адресу NULL», чего в стандарте явно не написано (см ваш перевод и оригинальный текст, которые я привел).

    >перевешивают мнение таинственного dimoclus без единой публикации
    Будьте любезны не скатываться на личности и уж тем более не приводить число публикаций на хабре в качестве объективного критерия компетентности.
  • Разыменовывание нулевого указателя приводит к неопределённому поведению
    +1
    Я не придумываю. Я привел две цитаты из стандарта, которые трактуются весьма однозначно и не оставляют поля для маневра.
    В плюсах для не POD-типов есть нюасны, но стандарт плюсов — это совсем другая история.
    Приведенная вами цитата

    в Разделе 6.3.2.3 «Указатели» сказано следующее:
    Если константа нулевого указателя приводится к типу указателей, то результирующий указатель, называемый нулевым, гарантированно будет не равен указателю на любой объект или функцию.

    рекомендуется к повторному прочтению на языке оригинала:

    If a null pointer constant is converted to a
    pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
    to a pointer to any object or function.

    Это означает, что any_valid_object_or_function_pointer != NULL всегда истинно.
    Трактовка «нулевой указатель не указывает на объект, поэтому к его полю нельзя обратиться даже для вычисления адреса» смахивает на подмену понятий.

    Вообще говоря, давайте вместе почитаем вот это (6.3.2.1 Lvalues, arrays, and function designators, п 2):

    Except when it is the operand of the sizeof operator, the _Alignof operator, the
    unary & operator, the ++ operator, the — operator, or the left operand of the. operator
    or an assignment operator, an lvalue that does not have array type is converted to the
    value stored in the designated object (and is no longer an lvalue); this is called lvalue
    conversion.

    Я долго думал, а потом прочитал это как

    Кроме случаев, когда lvalue является аргументом операторов sizeof/alignof/унарного &/инкремента/декремента или левой частью оператора «.» или присваивания, lvalue, не являющееся массивом, преобразуется к значению, хранящемуся в означенном объекте.

    Это по факту говорит нам, что чтения значения из lvalue при взятии от него адреса не происходит (а также sizeof(podh->line6), _Alignof(podh->line6)) => нет никакого разыменования => нет UB.
  • Разыменовывание нулевого указателя приводит к неопределённому поведению
    +1
    Что-то я крайне сомневаюсь, что тут есть какое-то UB.
    Читаем стандарт, нам понадобятся два пункта:

    6.2.5 Types
    A structure type describes a sequentially allocated nonempty set of member objects
    6.5.3.2 Address and indirection operators
    The unary & operator yields the address of its operand. If the operand has type ‘‘type’’,
    the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator,
    neither that operator nor the & operator is evaluated and the result is as if both were
    omitted.

    Ну а дальше начинаем толковать стандарт:

    &podh->line6
    /*1*/ = &(*podh).line6
    /*2*/ = &(*(struct usb_line6*)((char*)podh + offsetof(struct usb_line6_podhd, line6)))
    /*3*/ = (struct usb_line6*)((char*)podh + offsetof(struct usb_line6_podhd, line6))

    Первый переход просто «по определению», второй — потому что структуры состоят из «последовательно расположенных непустых полей», ну а (3) даже специально прокомментирован в стандарте (страница 89, сноска 102 внизу страницы):

    Thus, &*E is equivalent to E (even if E is a null pointer)

    Где здесь UB?
  • Что каждый программист должен знать про оптимизации компилятора
    +4
    Каждый программист должен знать, что ни один компилятор не сможет заменить пузырьковую сортировку на quick/heap/mergesort, поэтому разработчику следует сосредоточиться на алгоритме, а об использовании кеша/выделении регистров нужно задумываться не раньше запуска профайлера.
    Писать, уж простите, кучу говнокода, сваливая в кучу boost::tuple, boost::variant, std::map<std::string, std::vector<std::set<..>>>, уповая на силу аббревиатур PGO и LTO ни в коем случае нельзя.
    P. S. навеяно непреодолимой тягой немалого количества C++-программистов приёмам из однострочников на perl/python/ruby (посчитать количество запятых в строке? Легко: string.split.size() и т. п.)
  • Как я полюбил vim, Emacs и клавиатуру
    –1
    Есть ещё варианты

    Никогда не пойму 10 типов людей: тех, кто парсит html регэкспами и тех, кто регулярками рефакторит.
    Благодаря clang есть свет в конце тоннеля: github.com/bbchung/clighter помимо семантической подсветки умеет семантическое преобразование. К сожалению, пока работает не всегда корректно + чтобы переименовать сивол во всем проекте, нужно открыть все требуемые файлы. Но есть надежда, что дальше будет лучше.
  • PHP 7 получит в два раза более эффективный Hashtable
    0
    совершенно внутренняя вещь, такая, как конкретная реализация работы с hashtable

    А как же бинарная совместимость (собственноручно написанных) нативных расширений? Подобные проблемы вылезут в виде segmentation fault черте где, а не в виде сообщения интерпретатора о синтаксической ошибке, так что не бекпортировать такие вещи вполне разумное решение.
  • Насколько медленны iostreams?
    +1
    А не отпугивает от потоков, кхм, некоторая многословность?
    printf("%.2f\n", count * 100.0 / total);
    vs
    std::cout << std::setprecision(2) << std::fixed << count * 100.0 / total << std::endl
    + во времена g++ 3.3-4.0 в ostringstream была утечка памяти — с тех пор отношусь к ним с большой подозрительностью
  • Об удобной навигации и отладке C++ кода в Vim
    0
    Ещё мне нужно вынести часть кода метода в отдельный метод

    А еще не помешало бы научиться читать и усваивать прочитанное: русским по белому было написано, что рефакторинг и навигация в IDE (пока) лучше.
  • Об удобной навигации и отладке C++ кода в Vim
    –3
    Vim-режим включается в настройках. Этот режим чего-то нужного не эмулирует?

    Это сложно объяснить тому, для кого «модальное редактирование», имеет два состояния: бибикать после нажатия и все портить после .

    vim — единственный на сегодня редактор, делающий упор на модальное редактирование. Современные IDE очень далеко шагнули в плане рефакторинга, навигации, дополнения кода — без всего этого они просто notepad.exe, а модальный режим там реализован убого и, скорее, «для галочки». Эти notepad'ные кишки постоянно вылезают в самое неподходящее время: в коде символ «some_long_function_name», а нужно сделать из нее «some_not_so_short_name»? Жмем «f_lc2t_not_so_short», чтобы перейти к началу «long», а затем удалить все до «_» перед «name» понадобилось всего три команды:
    1. найти «_» (f_)
    2. двинуться на символ вправо (l)
    3. удалить весь текст до второго «_» и перейти в режим редактирования (c2t_)

    Когда начинаешь воспринимать редактирование не как «удалить 20 символов», а «удалить три следующих слова» или «очистить до «)», все становится значительно быстрее и, главное, ошибок становится меньше.
  • Сериализация и С++11
    +3
    отлаживать такой код очень затруднительно

    Что в данном случае подразумевается под «отладкой»? Пошаговая трассировка в отладчике — да, это может быть затруднительно, если макрос сплошь состоит из вызовов функций. А вот в плане отладки «во что это экспандится» макросы на много голов выше шаблонов: начиная от gcc -E и заканчивая отладкой макроэкспанда в gdb.
    P. S. только слепые рабы Саттера и Александреску боятся макросов, нормальные разработчики используют все доступные средства для повышения выразительности и читаемости кода.
  • Github опять заблокирован
    +15
    А что за способы самоубийства?
    kill(getpid(), 9)
    или
    *(int*)NULL = 42
    или что-то более изящное?

    Я в некоторых проектах raise(SIGTRAP) использую, мои исходники могут заблокировать как «безнравственные»?
  • Comment from a drafted post.
  • Как работает перенос сотового номера к другому оператору: FAQ и опыт разработки
    +2
    Наичие задолженности проверяется несколько раз, а как же быть с остатком на счету? Что с ним происходит при переносе номера?
  • Проект Miranda NG получает приз «дикие указатели» (часть первая)
    +6
    Плюс в англоязычной среде этикет немного другой

    /me вспоминает пальцы Линуса, его опусы про gcc-4.9 и многое другое.

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