Комментарии 35
Если кто интересуется, вот информация.
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.
Тут все понятно из предупреждения анализатора — в случае неудачного выделения памяти будет брошено исключение, а не возвращён нулевой указатель. Проверка не имеет смысла.А если поддержка исключений в принципе отключена в опциях компилятора, что произойдет? Или слинковано с nothrownew.obj для некоторых особо интересных компиляторов.
gcc -fno-exceptions насколько я понимаю будет вызывать abort. Чтобы вместо исключения new возвращал nullptr надо вызывать new(std::nothrow).
Во встроенном По, например, ексепшенов нет по умолчанию. Да и вообще они там редко применяются.
Да, но она поддерживается компилятором по умолчанию. Т. е. Heap и оператор new никто не отменял. А исключения нет, они для Embedded C++ включаются отдельно, так же как и RTTI, например.
Как вариант это не случайные ошибки, а намеренно оставленные телегой для последующей эксплуатации. Трудно поверить в то, что телега нанимает быдлокодеров и не проверяет свой код анализаторами.
«Похоже, в этом месте разработчики перепутали возвращаемый статус ошибки. По всей видимости, функция должна возвращать отрицательное значение в случае неудачи, а не true/false. По крайней мере, именно возврат значения -1 можно наблюдать в коде ниже.» — весь код не приведен, но судя по объвлению переменной r, функция возвращает тип int, а не bool. Объясните пожалуйста в чем я не прав? Там же обычное true of false? r: -1
Призеры чемпионата мира, очень быстро ставшие миллионерами. Может оно и правда круто, а вот публикация MTProto была как серия плевков, и еще эта попытка своего, особенного шифрования. Джобс кумир для Дурова, а сам Дуров теперь кумир для немалого числа разработчиков. И почему мне не нравится такой заносчивый стиль?
Интересно, ругнётся ли PVS Studio на сравнение переменной типа float или double с самой собой? Это может использоваться для проверки, равна ли переменная NAN. Да и оператор "==" может быть перегружен.
В любом случае полезно предупредить об этом разработчика, а он пусть уже анализирует, правильный это код, или нет.
Нет ли в планах сделать инспекцию, которая ругается на магические числа типа 2, 3, 4, 5, 6?
В коде нельзя так использовать голые числа. Нужно завести константы со смысловыми названиями. В данном случае, должно быть что вроде:
const int LEQ = 6;
или enum.
Магические числа, как минимум, ухудшают читаемость кода, а зачастую приводят к ошибкам. В IDEA такие проверки имеются.
Нет ли в планах сделать инспекцию, которая ругается на магические числа типа 2, 3, 4, 5, 6?Нет.
Подобная инспекция относится к классу крайне шумных. Прошу прочитать эту заметку, чтобы понимать нашу позицию, что много предупреждений, не значит хорошо.
Мы можем сделать подобную диагностику только в том случае, если она будет входить в один из поддерживаемых стандартов, таких как MISRA. Но кстати, даже в MISRA подобного нет. Есть поиск восьмеричных констант, беззнаковых без суффикса U и так далее, но не просто чисел.
Ещё вариант, это реализация подобной диагностики в разделе «Customers Specific Requests» по запросу клиента. Они по умолчанию выключены. Становитесь нашим клиентом и сделаем подобную диагностику. А бесплатно такую ужасную диагностику мы делать не будем :).
С удовольствием бы стал вашим клиентом, даже без этой диагностики. К сожалению, пока не могу себе этого позволить.
Проверка кода Telegram Open Network анализатором PVS-Studio