Comments 54
V547, Expression 'adjustedOctave < 8' is always false
может он имел ввиду "'adjustedOctave <= 8'"?
Просмотр?
И потом, это мог быть «не используемый», но нужный код для отладки? Ведь если он хотел, допустим из любопытства посмотреть «а можно» транспонировать на 9 октав ( хотя у фортепиано всего 8-мь )?
Как — то Вы проверяете вязь колдовских символов, а что проверяете, домен знания, видимо нтуитивно не охватываете.
Буду глядеть дальше, если будет время. Спасибо за интересые данные по музыкальному ПО :)
***
Может Вам в бухгалтерские пастбища попастись. Верьте или нет, как то такого же жучка нашел на интерфейсе сверстки бюджета
if( budget = 0 )
{
budget = 0 + ( сложные вычисления после запятой );
}
*********
Сложный вопрос… это ведь не служебное приложение. Почему не делегировать ОС утечку ресурса озу вместе с дескриптором? Где гарантия, что попытка закрыть источник утечки, пользуясь ресурсом библиотеки стандартных сбоев, справится лучше. Ведь сбой, наверняка будет тоже, жучком ОС.
Какой такой наверняка жучок ОС? Тут скорее рассматриваются случаи вида "нет прав на чтение файла" или "файл заблокирован пишущим процессом".
>>…
>> Какой такой наверняка жучок ОС? Тут скорее рассматриваются случаи вида «нет >> прав на чтение файла» или «файл заблокирован пишущим процессом».
Для того, чтобы
V773 The function was exited without releasing the 'testFile' pointer. A memory leak is possible.
был возможен, этот блок
std::ifstream *testFile =
new std::ifstream(filename.toLocal8Bit(),
std::ios::in | std::ios::binary);
if (!(*testFile))
return UNKNOWN;
должен отработать безупречно, и вылететь в области, изящно обоначенной многоточием
"..."
А вот за ответ на вопрос «Какой такой наверняка жучок ОС?» Майкроофт и Гугл платят по 15 тыщ в твердой валюте, каждый, поштучно.
Так что не прикидывайтесь дурачком и ставьте крестик, пока не закадрил Ваш эккаунт НЛО. Я вообще человек исключительной доброты и терпения, но с невежественными хамами у меня разговор короткий.
Вы ошибаетесь, утечка памяти возникнет при выполнении return UNKNOWN;
. Область обозначенная многоточием тут ни при чем.
Так что не прикидывайтесь дурачком и ставьте крестик, пока не закадрил Ваш эккаунт НЛО. Я вообще человек исключительной доброты и терпения, но с невежественными хамами у меня разговор короткий.
Спасибо, повеселили.
return UNKNOWN;.
значит дескриптора нет. Без дескриптора нет утечки. Вы вообще думаете, что пишете? Чтобы был ресурс, у которого есть риск утечки, код должен пройти обсуждаемый блок без ошибок и получить ресурс — дескриптор от ОС, и вылететь где -то по дороге к
testFile->close();
Как же Вы не понимете…
Так тут утечка памяти же. Под testFile
память была выделена, а освободить ее забыли.
PS Вы вообще думаете, что пишете?
std::ifstream
— это обычный класс, который технически ничем не отличается от других классов. В частности, он имеет ненулевой размер.
Так что std::ifstream *testFile
— это именно что указатель на блок в памяти.
Указатель не на блок памяти.А на что тогда?
Напишите, пожалуйста, название компании в которой Вы работаете. Мне кажется, этой компании срочно требуется анализатор кода PVS-Studio и я попробую связаться с руководством. Я представляю, что там напрограммировано… :)
После чего перепроверил и нашел, что ошибся.
Исключение представляет вызов файла, которого нет.
После чего предлагаю Вам настойчиво перечитать комментарий автора(ов)
«Если с файлом возникают проблемы, то указатель testFile не освобождается при выходе из функции. Это распространённый паттерн, приводящий к утечке памяти.»
Быть может, Вы путаете C++ с каким-то другим языком, где встроен сборщик мусора?
std::ifstream *testFile = new std::ifstream(filename.toLocal8Bit(), std::ios::in | std::ios::binary);
Создали объект и положили указатель в обыкновенную переменную. Где вызов delete testFile?
Результат — утечка.
«Если с файлом возникают проблемы, то указатель testFile не освобождается при выходе из функции. Это распространённый паттерн, приводящий к утечке памяти.»
Смысл парагафа статьи в том, что код действительно имеет некоторые, трудно уловимые огрехи, которые могут убить служебное ПО, у которого подобная утечка может стать причиной резкого снижения производительности, которое практически невозможно «поймать» пользуясь диагностикой или trace. Вдруг программа начинает работать медленно… и прекрасно «расправляет крылья» после перезапуска. В режиме обслуживания ползователей, или под stress test.
Без такого анализатора поиск источника потерь может затянутся на месяцы. Миллиардные вложения в разработку ПО могут быть потеряны.
Запирать их в try / catch не решает проблему, поскольку источник во вне try/catch, и шлифовка требует полной интеграции с OS по всем векторам срыва. Простыни с спорами, как это делать, пестреют на некоторых форумах, и их очень интересно читать. Это тома, которые обычно кончаются в ассемблере, и авторы никогда не приходят к согласию. У музыкального ПО нет ресурсов, чтобы так глубоко исследовать компьютеры, а учитывая что человек пишущий ноты сидит у экрана и при срыве может отреагировать нажав на кнопку «OK/Cancel» просто не очень резонно.
Что действительно помогает, это отдельный поток, фиксирующий изменения внесённые рукой пользователя, чтобы такой вот внезапный срыв не испортил, скажем, три месяца работы композитора.
— Oпределение тональности не верно.
Вот код:
case MIDI_KEY_SIGNATURE:
tonality = (int)midiEvent.m_metaMessage[0];
if (tonality < 0) {
sharpflat = -tonality + " flat";
} else {
sharpflat = tonality;
sharpflat += " sharp";
}
— вот спецификации:
4.1 MIDI Key Signature meta message
The MIDI key signature meta message specifies the key signature and scale of a MIDI file.
This message belongs to the category of MIDI meta messages. Since this is a meta message the MIDI event that carries this message may exist in MIDI files, but it is not sent over MIDI ports to a MIDI device.
This message consists of five bytes of data. The first byte is the status byte 0xFF, which shows that this is a meta message. The second byte is the meta message type 0x59, which shows that this is the key signature meta message. The third byte is 0x02, which shows that there are two remaining bytes. The fourth byte has values between -7 and 7 and specifies the key signature in terms of number of flats (if negative) or sharps (if positive). The fifth and last byte of the message specifies the scale of the MIDI file, where if this byte is 0 the scale is major and if the byte is 1 the scale is minor.
— Может у автора кода есть решение, которое где то затерялось. Если нет, мне кажется можно решить не используя циклы, но если не придумаю ничего интересного, напишу циклами.
Похоже, что это общая черта музыкальных проектов. Я участвовал в разработке одного приложения из топ 10 музыкального раздела iTunes. Это был проект с худшим кодом, который я встречал за всю свою программистскую практику.
Например darktable
Что касается недсотижимого кода, то это распространенное явление после больших правок — иногда лень чистить, иногда нет времени. Однако кроме как расход лишней памяти на диске у разработчика никаких последствий не несет — компилятор все это просекает, сообщает, если предупреждения не отключены, а код не генерирует в любом случае.
Во многих проектах куча классов, функций и методов, которые никогда не включаются в результат просто потому, что лень править CmakeLists.txt
Что касается недсотижимого кода, то это распространенное явление после больших правок — иногда лень чистить, иногда нет времени. Однако кроме как расход лишней памяти на диске у разработчика никаких последствий не несет — компилятор все это просекает, сообщает, если предупреждения не отключены, а код не генерирует в любом случае.
А как же тогда быть, например, с уязвимостью CVE-2014-1266 в iOS? Чуть подробнее см. здесь.
iOS здесь при чем? Речь же об опенсорс?
static
Bool doHelperCallWithArgsOnStack (....)
{
....
if (guard) {
if (guard->tag == Iex_Const
&& guard->Iex.Const.con->tag == Ico_U1
&& guard->Iex.Const.con->Ico.U1 == True) {
/* unconditional -- do nothing */
} else {
goto no_match; //ATC
cc = iselCondCode( env, guard );
}
}
....
}
Подробнее.
Я, например, всегда полный оператор if пишу со всеми вариантами и скобками, даже если никогда в них никакого кода не будет. Например:
if (a == b) {
do_something();
} else {
}
И дрючу тех, кто пишет так:
if (a == b) {
do_something();
}
или, не приведи бог, так
if (a == b)
do_something();
Иногда выбрасывается большая часть кода с помощью goto, что гораздо безопаснее, чем комментить блок.
V670 редкая, скорее всего, потому что gcc (да и вообще многие компиляторы) ругаются на разный порядок переменных в объявлении и в конструкторе.
Скажем, вот на такое
#include <iostream>
using namespace std;
struct Test {
int var1;
int var2;
int var3;
Test() : var2(42), var1(var2), var3(var1) {}
void run() {
cout << var1 << " " << var2 << " " << var3 << endl;
}
};
int main() {
Test test;
test.run();
return 0;
}
gcc ругается как-то так
test.cpp: In constructor 'Test::Test()':
test.cpp:6:6: warning: 'Test::var2' will be initialized after [-Wreorder]
int var2;
^~~~
test.cpp:5:6: warning: 'int Test::var1' [-Wreorder]
int var1;
^~~~
test.cpp:8:2: warning: when initialized here [-Wreorder]
Test() : var2(42), var1(var2), var3(var1) {}
^~~~
а clang чуть поумнее и поэтому ругается как-то так:
test.cpp:8:11: warning: field 'var2' will be initialized after field 'var1'
[-Wreorder]
Test() : var2(42), var1(var2), var3(var1) {}
^
test.cpp:8:26: warning: field 'var2' is uninitialized when used here [-Wuninitialized]
Test() : var2(42), var1(var2), var3(var1) {}
^
2 warnings generated.
Берем этот пример:
bool
MidiFile::write(const QString &filename)
{
std::ofstream *midiFile =
new std::ofstream(filename.toLocal8Bit(),
std::ios::out | std::ios::binary);
if (!(*midiFile)) {
RG_WARNING << "write() - can't write file";
m_format = MIDI_FILE_NOT_LOADED;
return false;
}
....
midiFile->close();
return true;
}
Параметром передается путь файла типа QString. Потом зачем-то вместо QFile используется ofstream. Потом строка конвертируется с помощью toLocal8Bit, то есть с большой вероятностью не latin символы потеряются. Ну и потом все эти проблемы с утечками.
Но в данном участке кода (и, по всей видимости, не только в нем) проблема от не очень хорошего знания самих плюсов, и фреймворка Qt в частности. Серьезно, ошибки уровня студентов 1 курса.
Обзор дефектов кода музыкального софта. Часть 3. Rosegarden