23:55
Зазеркалье
С детства нас учат правильно выбирать тип переменной. Например, если числа она должна представлять только положительные, её можно сделать типа unsigned int -- тогда она сможет представить в два раза больший набор значений.
Итак, в одном из проектов у нас есть маленький модуль. Он реализует обработку команд на специальном птичьем языке програмирования. Он был придуман давным-давно, ещё до моего прихода в нашу организацию. Этот язык не поддерживает условия, но поддерживает циклы. Перед выполнением циклы "разворачиваются", в итоге получается фиксированная последовательность команд без переходов, которая исполняется последовательно.
То есть, до разворачивания макрос выглядел так:
loop 3
command1
command2
endloop
А после разворачивания так:
nop
command1
command2
nop
nop
command1
command2
nop
nop
command1
command2
nop
По тактическим соображениям команды начала и конца цикла не удалялись, а заменялись на nop (пустая команда).
Циклы поддерживались только одного уровня вложенности, в то время как существовала необходимость сделать циклы минимум вложенности 2. Это задание было выдано мне. Я решил сразу делать цикл вложенности n. Как определять границы циклов -- плёвая задача. В итоге я написал функцию:
void Unfold(CMacros *pMacros, unsigned int nStart, unsigned int nEnd);
Она должна была брать макрос pMacros, извлекать из него заданный набор команд -- от номера nStart до номера nEnd -- повторять их заданное число раз (тут этот момент опущен) и вставлять после первого встречания тела цикла. Там было написано примерно следующее:
InsertAt -- вставляет в заданную позицию, сдвигая то, что там было (и всё дальнейшее), дальше по массиву.
aCommands -- массив команд.
GetAt -- обращение к массиву по заданному индексу.
Эта штука работала без нареканий 2 года. Но сегодня ружьё выстрелило. Программа падает. Почему? Выход за границы массива в GetAt.
ОКАЗАЛОСЬ, что nStart равен нулю. Два года работы, десятки скриптов. Ни у одного из них начало цикла не было первой командой! Поэтому значение типа unsigned int (переменная x) всегда сравнивалось с числом 1 или больше (очевидно, первая команда имела номер 0, а не 1). И когда оно становилось равно в худшем случае нулю, цикл прекращался. Когда же цикл оказался стоящим первой командой, возникла прикольная ситуация. Число типа unsigned всегда будет больше либо равно нуля! Если из него вычесть 1, оно станет равно 2^32-1 (если int 32 бита). Перенос! И по этому четырёхмиллиардному смещению программа пытается что-то там прочитать.
Я смотрю на это и говорю -- а давайте поменяем тип x на int. Тогда он станет равным -1, а -1>=0 это ложь. Т.к. условие в цикле for проверяется ДО тела, то цикл завершится ещё до того, как -1 попадёт в аргумент GetAt.
Сделали. Но не помогло. Происходил вход в тело цикла! Тогда мы заменили nStart и nEnd тоже на просто int -- и всё заработало!
Что это означает? Что при проверке условия x>=nStart по неизвестной причине int преобразуется к unsigned int, а не наоборот! И -1 при сравнении превращалась в ту же 2^32-1 или может и во что похуже, но это значения не имеет, т.к. оно было типа unsigned int, а любое число этого типа будет заведомо больше либо равно нулю.
Мораль. Не использовать тип unsigned в циклах с обратным счётом. Тут такой цикл был нужен, чтобы вставлять команды в одну и ту же точку массива, сдвигая его конец всё дальше. Чтобы порядок команд не стал обратным, надо было запихивать их в массив задом наперёд, но по одному и тому же смещению.
Итак, в одном из проектов у нас есть маленький модуль. Он реализует обработку команд на специальном птичьем языке програмирования. Он был придуман давным-давно, ещё до моего прихода в нашу организацию. Этот язык не поддерживает условия, но поддерживает циклы. Перед выполнением циклы "разворачиваются", в итоге получается фиксированная последовательность команд без переходов, которая исполняется последовательно.
То есть, до разворачивания макрос выглядел так:
loop 3
command1
command2
endloop
А после разворачивания так:
nop
command1
command2
nop
nop
command1
command2
nop
nop
command1
command2
nop
По тактическим соображениям команды начала и конца цикла не удалялись, а заменялись на nop (пустая команда).
Циклы поддерживались только одного уровня вложенности, в то время как существовала необходимость сделать циклы минимум вложенности 2. Это задание было выдано мне. Я решил сразу делать цикл вложенности n. Как определять границы циклов -- плёвая задача. В итоге я написал функцию:
void Unfold(CMacros *pMacros, unsigned int nStart, unsigned int nEnd);
Она должна была брать макрос pMacros, извлекать из него заданный набор команд -- от номера nStart до номера nEnd -- повторять их заданное число раз (тут этот момент опущен) и вставлять после первого встречания тела цикла. Там было написано примерно следующее:
unsigned int x;
for(x=nEnd;x>=nStart;x--)
{
pMacros->aCommands->InsertAt(nEnd+1,pMacros->aCommands->GetAt(x));
}
InsertAt -- вставляет в заданную позицию, сдвигая то, что там было (и всё дальнейшее), дальше по массиву.
aCommands -- массив команд.
GetAt -- обращение к массиву по заданному индексу.
Эта штука работала без нареканий 2 года. Но сегодня ружьё выстрелило. Программа падает. Почему? Выход за границы массива в GetAt.
ОКАЗАЛОСЬ, что nStart равен нулю. Два года работы, десятки скриптов. Ни у одного из них начало цикла не было первой командой! Поэтому значение типа unsigned int (переменная x) всегда сравнивалось с числом 1 или больше (очевидно, первая команда имела номер 0, а не 1). И когда оно становилось равно в худшем случае нулю, цикл прекращался. Когда же цикл оказался стоящим первой командой, возникла прикольная ситуация. Число типа unsigned всегда будет больше либо равно нуля! Если из него вычесть 1, оно станет равно 2^32-1 (если int 32 бита). Перенос! И по этому четырёхмиллиардному смещению программа пытается что-то там прочитать.
Я смотрю на это и говорю -- а давайте поменяем тип x на int. Тогда он станет равным -1, а -1>=0 это ложь. Т.к. условие в цикле for проверяется ДО тела, то цикл завершится ещё до того, как -1 попадёт в аргумент GetAt.
Сделали. Но не помогло. Происходил вход в тело цикла! Тогда мы заменили nStart и nEnd тоже на просто int -- и всё заработало!
Что это означает? Что при проверке условия x>=nStart по неизвестной причине int преобразуется к unsigned int, а не наоборот! И -1 при сравнении превращалась в ту же 2^32-1 или может и во что похуже, но это значения не имеет, т.к. оно было типа unsigned int, а любое число этого типа будет заведомо больше либо равно нулю.
Мораль. Не использовать тип unsigned в циклах с обратным счётом. Тут такой цикл был нужен, чтобы вставлять команды в одну и ту же точку массива, сдвигая его конец всё дальше. Чтобы порядок команд не стал обратным, надо было запихивать их в массив задом наперёд, но по одному и тому же смещению.