Как стать автором
Обновить

Комментарии 35

PVS Studio делает самую полезную рекламу на хабре. Думаю что можно смело подавать заявку на конкурс Телеграма и получать свой приз! Разработчики как настоящие джентльмены теперь обязаны жениться приобрести подписку или дать один из призов.

Если кто интересуется, вот информация.

Here’s how to submit your code for the blockchain contest (https://t.me/contest/102) depending on the goal at hand:

1. Submit an archive containing your source code, a howto manual and a build script (if necessary) to @jobs_bot (choose Blockchain Contest).

Or:

2. Submit a pull request with the TON VM/compiler improvement on GitHub. Describe the issue in the comment to your pull request. In addition, submit the link to the pull request and an archive as described in 1. demonstrating the new features suggested in the pull requests to @jobs_bot.

Or:

3. Submit a pull request on GitHub. Describe the issue in the comment to the pull request. Submit the link to the pull request to @jobs_bot.
Так там есть уже хоть один пруф, что TON имеет отношение к Telegram вообще?
В телеграм от телеграм пришла рассылка с конкурсами, где, кроме всего прочего, предлагается конкурс на разработку смартконтрактов для этой платформы. Так что теперь нет ни одного сомнения, что он имеет отношение к телеге.
А, ну вот и комментарий выше тоже о нём. Интересно, чего же они шифровались так до этого тогда? ;-) Там целую конспирологию успели развести.
Неплохая пиар стратегия, почему бы и нет. Развели конспирологию, долго и много обсуждали и все это — без больших затрат со стороны телеграмма.
Если у Apple до презентации нового айфона спросить про уже утёкшую информацию о нём, там точно так же ответят «достоверная информация только в официальных каналах, всё остальное мы не комментируем».
Кошелек с грамами готовятся звести: telegram.org/tos/wallet
Тут все понятно из предупреждения анализатора — в случае неудачного выделения памяти будет брошено исключение, а не возвращён нулевой указатель. Проверка не имеет смысла.
А если поддержка исключений в принципе отключена в опциях компилятора, что произойдет? Или слинковано с nothrownew.obj для некоторых особо интересных компиляторов.

gcc -fno-exceptions насколько я понимаю будет вызывать abort. Чтобы вместо исключения new возвращал nullptr надо вызывать new(std::nothrow).

А если у класса переопределен оператор new? Вызван же будет он, а вдруг он делает malloc?

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

Во встроенном По, например, ексепшенов нет по умолчанию. Да и вообще они там редко применяются.

Там и динамическая аллокация обычно противопоказана.

Да, но она поддерживается компилятором по умолчанию. Т. е. Heap и оператор new никто не отменял. А исключения нет, они для Embedded C++ включаются отдельно, так же как и RTTI, например.

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

Согласен.

«За что, конечно же, стоит отдать должное программистам из команды Telegram. Однако от ошибок не застрахованы даже они.»
Как вариант это не случайные ошибки, а намеренно оставленные телегой для последующей эксплуатации. Трудно поверить в то, что телега нанимает быдлокодеров и не проверяет свой код анализаторами.
Вы видимо никогда не работали в крупных, считающихся крутыми, технологических компаниях. Бардак есть всегда и везде, идеально вряд ли вообще хоть кто-то делает. Особенно на старте проекта когда он еще не оброс бюрократией и процессы могут быстро меняться.
Это типичные ошибки крупного проекта, совершаемые по недосмотру и/или в запаре/дедлайне, а не быдловство, как вам кажется. Вы не программист, если таких ошибок никогда не совершали. И да, шапочку из фольги не забудьте надеть когда будете в Телеграм выходить, лишний тернарный оператор украдет ваши данные, видите, там вначале стоит единица, а это не иначе как часть номера вашей банковской карты, гнусные разрабы и сюда свои ручонки запихнули!
Извиняюсь, я могу ошибаться — я не разрабатываю на плюсах и сях, но
«Похоже, в этом месте разработчики перепутали возвращаемый статус ошибки. По всей видимости, функция должна возвращать отрицательное значение в случае неудачи, а не true/false. По крайней мере, именно возврат значения -1 можно наблюдать в коде ниже.» — весь код не приведен, но судя по объвлению переменной r, функция возвращает тип int, а не bool. Объясните пожалуйста в чем я не прав? Там же обычное true of false? r: -1

В самом начале примера:


    if ((shard.shard & 1) || cs.size_ext() != 0x20000) {
      return false;                                     // <= Вот тут
    }
Может они комментарии специально вычищают перед тем, как выложить исходники? Этот их элитаризм уже начинает влиять на культуру разработки. Пишешь документацию и заботишься, чтобы тебя поняли? Ну значит ты глупый и никчемный, звезды так не делают.

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

Интересно, ругнётся ли PVS Studio на сравнение переменной типа float или double с самой собой? Это может использоваться для проверки, равна ли переменная NAN. Да и оператор "==" может быть перегружен.
В любом случае полезно предупредить об этом разработчика, а он пусть уже анализирует, правильный это код, или нет.

Нет. Не будет ругаться. Это слишком часто встречается в коде. Это указано в документации на V501. Идея, что лучше ругаться на всё подряд, а программист уж разберётся, к сожалению, контрпродуктивна.

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

Нет ли в планах сделать инспекцию, которая ругается на магические числа типа 2, 3, 4, 5, 6?

В группе 64-х битных диагностик есть поиск 4, 8, может ещё каких-то чисел, кратных размеру указателя. А что особенного в других приведённых числах?

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


const int LEQ = 6;

или enum.


Магические числа, как минимум, ухудшают читаемость кода, а зачастую приводят к ошибкам. В IDEA такие проверки имеются.

В приблизительных математических расчётах вещи типа 2, 6, 24, 120 — нормальное явление.
Понятно что есть случаи когда имеет смысл такую проверку выключать. Но мне кажется это случаи более редкие чем те, где было бы неплохо иметь ее из коробки.

Если у числа есть размерность (метры, вольты, киловаттчасы), то вместо него в расчетах должен быть символ.

Нет ли в планах сделать инспекцию, которая ругается на магические числа типа 2, 3, 4, 5, 6?
Нет.

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

Мы можем сделать подобную диагностику только в том случае, если она будет входить в один из поддерживаемых стандартов, таких как MISRA. Но кстати, даже в MISRA подобного нет. Есть поиск восьмеричных констант, беззнаковых без суффикса U и так далее, но не просто чисел.

Ещё вариант, это реализация подобной диагностики в разделе «Customers Specific Requests» по запросу клиента. Они по умолчанию выключены. Становитесь нашим клиентом и сделаем подобную диагностику. А бесплатно такую ужасную диагностику мы делать не будем :).

С удовольствием бы стал вашим клиентом, даже без этой диагностики. К сожалению, пока не могу себе этого позволить.

Как я понял в PVS Studio начиная с версии 6.27 (2018 года) можно включить полноценную проверку на соответствие кода стандарту MISRA C и MISRA C++? https://www.viva64.com/ru/b/0596/
На данный момент есть следующий список поддерживаемых правил и он постоянно пополняется.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.