• Англоязычная версия Хабра: быть или не быть?
    +2
    Команда PVS-Studio всячески за. Тем более, что у нас и так все статьи сразу и на русском и английском. Готовы поспособствовать материалом и деньгами.
  • 31 февраля
    +4
    А нам даже ничего специально делать не пришлось. Возможность сама «подхватилась» из C++ — ядра.

    image

    Так что думаю наш анализатор сможет порадовать пользователей. IDEA уже 10 лет, но понадобилась наша статья, чтобы добавить полезную диагностику. В общем, мы привнесём свежую кровь в сообщество Java анализаторов :).
  • Почему важно проверять, что вернула функция malloc
    +2
    Как много болтологии, чтобы оправдать нежелание и неумение обрабатывать ошибки. Мы сейчас занимаемся полноценной поддержкой компилятора Keil. В целях проверки (ложных срабатываний и т.п.) я сейчас разбираю отчёт об анализе проекта RT-Thread. И вот что интересно, почему-то там разработчики умеют обращаться с malloc. Проверяют и обрабатывают нехватку памяти (первый попавшийся пример):

        /* allocate memory */
        mp->start_address = rt_malloc((block_size + sizeof(rt_uint8_t *)) *
                                      block_count);
        if (mp->start_address == RT_NULL)
        {
            /* no memory, delete memory pool object */
            rt_object_delete(&(mp->parent));
    
            return RT_NULL;
        }
    
    Им это не кажется чем-то нереально сложным или ненужным. Вот они молодцы. Просто взяли и сделали обработку ошибок, а не занялись отмазками.

    P.S. Есть ли там ошибки? Конечно есть. Например, вот эта понравилась.
    void LCD_PutPixel (LCD_PANEL panel, uint32_t X_Left, uint32_t Y_Up, LcdPixel_t color)
    {
        uint32_t k;
        uint32_t * pWordData = NULL;
        uint8_t*   pByteData = NULL;
        uint32_t  bitOffset;
        uint8_t*   pByteSrc = (uint8_t*)&color;
        uint8_t  bpp = bits_per_pixel[lcd_config.lcd_bpp];
        uint8_t  bytes_per_pixel = bpp/8;
        uint32_t start_bit;
      
        if((X_Left >= lcd_hsize)||(Y_Up >= lcd_vsize))
            return;
    
        if(panel == LCD_PANEL_UPPER)
        pWordData = (uint32_t*) LPC_LCD->UPBASE + LCD_GetWordOffset(X_Left,Y_Up);
        else
        pWordData = (uint32_t*) LPC_LCD->LPBASE + LCD_GetWordOffset(X_Left,Y_Up);
        
        bitOffset = LCD_GetBitOffset(X_Left,Y_Up);
        pByteData = (uint8_t*) pWordData;
        pByteData += bitOffset/8;
        
        start_bit =  bitOffset%8;
    
        if(bpp < 8)
        {
          uint8_t bit_pos = start_bit;
          uint8_t bit_ofs = 0;
          for(bit_ofs = 0;bit_ofs <bpp; bit_ofs++,bit_pos++)
          {
              *pByteData &= ~ (0x01 << bit_pos);
              *pByteData |= ((*pByteSrc >> (k+bit_ofs)) & 0x01) << bit_pos; // переменная k неинициализированная
          }
        }
        else
        {
             for(k = 0; k < bytes_per_pixel; k++)
            {
               *(pByteData+ k) = *pByteSrc++;
            }
        }
    }
    PVS-Studio: V614 CWE-457 Uninitialized variable 'k' used. lpc_lcd.c 510
  • Почему важно проверять, что вернула функция malloc
    +4
    Отсутствие проверки после malloc — это не отсутствие перфекционизма. Это отсутствие профессионализма. И печально, что многие это считают нормой. Мельчает C++ программист :).

    P.S. А в прочем, это даже к лучшему. Будет больше возможностей продавать PVS-Studio, когда вдруг припрёт, и поделие таких «программистов» вдруг станет большим, востребованным, и окажется, что весь этот код надо как-то поддерживать и развивать. Благословляю на говнокодинг :).
  • Chromium: другие ошибки
    0
    Сейчас мы ещё дополнительно отвлеклись на полноценную поддержку Keil и IAR. Плюс поддержка macOS на подходе. Скоро пойдут публикации о разных новых возможностях С++ анализатора. Можно делать предзаказы.
  • Chromium: другие ошибки
    0
    Наша команда, как и прежде активно развивает возможности C++ анализатора. Например, готовится к выпуску сложная диагностика V1010, предназначенная для выявления использования недостоверных данных. А вообще, небольшое количество диагностик связано с тем, что сейчас в основном разработка ведётся «вширь». Усовершенствуется и обобщается Data Flow механизм, который будет использовать и в Java анализаторе. В результате, усовершенствования Data Flow анализа, старые диагностики начинают находить новые ошибки. Пример такого улучшения я недавно описывал в недавней статье "31 февраля".
  • Chromium: другие ошибки
    +1
    Планируем. Добавляем. Если наш доклад возьмут на конференцию JPoint, то расскажем, как мы разрабатываем этот анализатор. Надеюсь, к этому моменту будет что-то, что можно показывать. А вообще, Java анализатор, уже даже какие-то ошибки находит, но статьи писать про это рано.
  • Почему важно проверять, что вернула функция malloc
    0
    Да.

    P.S. Есть std::nothrow вариант оператора new, но это другая история.
  • Chromium: шестая проверка проекта и 250 багов
    0
    Последняя седьмая статья цикла: Chromium: другие ошибки.
  • Почему важно проверять, что вернула функция malloc
    +1
    В целом согласен, но хочу отметить:
    навредить другому приложению нет возможности.
    Достаточно навредить себе! Особенно если это большое, сложное параллельное приложение, где malloc вернул 0 в одном из потоков и поток был прибит, а приложение продолжит работать. Вот только, где-то что-то могло быть испорчено.
  • Почему важно проверять, что вернула функция malloc
    0
    в чем разница: 1234->member и null->member?
    Прошу уточнить вопрос.

    порча да, но только данных этого приложения же
    Этого мало? Уточню: надо думать не в контексте порчи памяти в игре тетрис :).
  • Почему важно проверять, что вернула функция malloc
    +1
    Да, данные сторонних приложений в современных ОС так просто не испортить. Однако, программе достаточно испортить собственные данные, чтобы возникли непредсказуемые эффекты. С начала испортили, потом перехватили исключение/сигнал и продолжили работать. Начали, например, аварийно данные сохранять. А ведь где-то что-то испорчено.
    Или испортили что-то в данных собственной параллельной нити. И пока программа из-за нехватки памяти готовилась к завершению работы (в лог про ошибку писала), эта параллельная нить с неверными данными способна ужас разный наделать.
  • Почему важно проверять, что вернула функция malloc
    +5
    Если целевая платформа это Linux с настройками по умолчанию: в принципе не то чтобы и нужна.
    Хочу заметить, что такое недопустимо для библиотек. Библиотека не знает, где и как её будут использовать. Например, тот-же Chromium, использующий кучу библиотек, работает в Windows, где malloc/realloc вполне может дать нулевой указатель, если запросили много или если память приложения сильно фрагментирована.
  • Почему важно проверять, что вернула функция malloc
    0
    Кому-то очевидно, что падать при первом поводе это плохая идея, а кому-то нет. :) Вот на реддите, например, статью и заминусовали и закритиковали.
  • Почему важно проверять, что вернула функция malloc
    +14
    вызывает malloc() с тем же параметром, если вернулся NULL — вызывает abort()
    Ради бога. Это как раз и есть та самая проверка, на которой я настаиваю и реакция на неё. Как решить проблему — это вторично. Главное начать её решать, а не надеяться, что если ничего не делать, то так всё само-собой хорошо будет ;).
  • Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
    –1
  • Красивый Chromium и корявый memset
  • Chromium: шестая проверка проекта и 250 багов
  • Chromium: шестая проверка проекта и 250 багов
  • Chromium: утечки памяти
    0
    С замечанием согласен.
  • Chromium: опечатки
    +1
    Возможно. Но проверить надо.
  • Chromium: шестая проверка проекта и 250 багов
    +1
    И ещё «услада» для глаз: Chromium: опечатки.
  • Chromium: шестая проверка проекта и 250 багов
    0
    Третья статья цикла: Chromium: утечки памяти.
  • Оператор break и fallthrough
    +1
  • Оператор break и fallthrough
    0
    Э… Что?
  • Оператор break и fallthrough
    +6
    Руководствуясь приведённой логикой, не следует развивать Spelling & Grammar чекер в Microsoft Office, лучше учить детей в школе языку. Лучше? Лучше. И что дальше?

    В общем, подобные рассуждения не имеют практического смысла. Только наша команда нашла в Open Source проектах уже 13483 ошибки. Причём у нас никогда не было цели найти как можно больше ошибок и это просто побочны продукт процесса написания статей. Думаю, общее количество ошибок, которые исправлены благодаря нашему инструменту, исчисляется сотнями тысяч. Можно рассуждать теоретически о том, как сделать мир лучше и как сделать, чтобы программисты не ошибались. Но вот только всё равно они ошибаются и найденные нами ошибки это подтверждают. Поэтому использование PVS-Studio это практический шаг по улучшению качества и надёжности кода. А философию мы оставляем философам :)

    Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.
    Как раз всё наоборот. Многим разработчикам open source приложений в инструментах статического анализа не нуждаются. В маленьких проектах низкая плотность ошибок и нет старого унаследованного кода, который никто не знает. Ну или на крайний случай можно воспользоваться бесплатным вариантом PVS-Studio. Зато этот инструмент нужен и полезен профессиональным разработчикам и компания может позволить им его купить.
  • Оператор break и fallthrough
    +1
    (del)
  • Оператор break и fallthrough
    +10
  • Оператор break и fallthrough
    +1
    Компиляторы по умолчанию ничего не сообщают, так как отсутствие break это изначальная фишка языка. В двойном присваивании одной переменной тоже ничего особенного нет. Так очень часто пишут. Поэтому в диагностике V519, выявляющей повторное присваивание, есть множество различных исключений.

    И я имел в виду, что раньше не использовался ключ, -Wimplicit-fallthrough (про него, кстати, говорится в статье). А теперь используется, что видно из общения в багтрекере разработчиков Chromium.

    Двойные присваивания искать — дело совсем неблагодарное. Нужен умный инструмент, такой как PVS-Studio, чтобы снижать шум.
  • Оператор break и fallthrough
    +1
    Теперь выдаёт :)

    Comment 1.
    Add a FALLTHROUGH macro and get base/ to build with -Wimplicit-fallthrough.

    Also fix a few missing breaks found by the warning in gpu/.
  • Chromium: шестая проверка проекта и 250 багов
    0
    Вторая статья цикла: Оператор break и fallthrough.
  • Chromium: шестая проверка проекта и 250 багов
    +1
  • Красивый Chromium и корявый memset
    0
    Нет. Часто проекты большие и сложно внимательно изучить все предупреждения. Соответственно, для них невозможно указать плотность ошибок. Для небольших проектов, таких как Notepad++, мы указываем плотность ошибок. И возможно при случае напишем статью сравнение. Но жаль, что в ней будут только такие небольшие проекты.
  • Красивый Chromium и корявый memset
    0
    Это зависит от реализации. Вот такая статья, например, попалась: A glance at compiler internals: Keep my memset.
  • Красивый Chromium и корявый memset
    +4
    Отлично! Меня радуют такие новшества в C++. С ними, анализатор PVS-Studio всегда будет нужен. :)
  • Красивый Chromium и корявый memset
    0
    путь что «и волки сыты и овцы целы»
    Это использовать такие функции, как memset_s. Компилятор знает, что от него хотят и обязательно затрёт память.
  • Красивый Chromium и корявый memset
    +4
    Примечание. sizeof не вычисляет выражение. Вычисляется только тип. sizeof(*переменная) не может привести к nullptr dereference.
  • Chromium: шестая проверка проекта и 250 багов
    +5
    Ещё у вас логотип CppCat классный был.
    Вот только проект CppCat закрыт, а PVS-Studio продолжает жить :).

    Проект CppCat вообще был «правильным». И логотип красивый, и цена «правильная» по лучшим рекомендациям людей. И сайт простой. И правильная система защиты от взлома. В общем, всё правильно было, вот только денег не приносило.

    А PVS-Studio с радужным единорогом, и по мнению многих неправильной стратегией рекламы, лицензирования и т.д., продолжает жить и привлекать новых пользователей ;). Жизнь она такая… Да…
  • Красивый Chromium и корявый memset
    0
    volatile object — an object whose type is volatile-qualified, or a subobject of a volatile object, or a mutable subobject of a const-volatile object. Every access (read or write operation, member function call, etc.) made through a glvalue expression of volatile-qualified type is treated as a visible side-effect for the purposes of optimization (that is, within a single thread of execution, volatile accesses cannot be optimized out or reordered with another visible side effect that is sequenced-before or sequenced-after the volatile access. This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order). Any attempt to refer to a volatile object through a non-volatile glvalue (e.g. through a reference or pointer to non-volatile type) results in undefined behavior.

    И из CWE-14: Potential Mitigations. Phase: Implementation. Store the sensitive data in a «volatile» memory location if available.
  • Красивый Chromium и корявый memset
    +3
    специальная функция от memset отличается чем?
    Тем, что она специальная. А как это достигается, прикладного программиста волновать не должно. Может использоваться какое-то непереносимое расширение компилятора.

    Если говорить про самодельные функции, то в них всё вертится вокруг volatile. Раз что-то volatile, то это нельзя оптимизировать и выбрасывать. Но вообще самоделки — это плохо. Это на крайний случай.