PICC18 Bug

Привет!

Thu Mar 31 2005 11:28, Harry Zhurov wrote to Alexander Golov:

...

AG>>>>>> void func () AG>>>>>> { AG>>>>>> signed char indx ; AG>>>>>> buf [ indx ] ++ ; AG>>>>>> }

AG>>>> Что тут ещё за неопределённое поведение?

AM>>> Использование неинициализированной автоматической переменной.

AG>> Hе запрещено и уж конечно никакой непопределённости не вносит.

HZ> В данном случае - в коде, который ты привел выше, - HZ> неинициализированная локальная переменная используется в качестве индекса HZ> массива и может привести к адресации за пределы оного массива, что HZ> порождает (по Стандарту хоть С хоть С++) неопредленное поведение.

Для начала, не будем путать неопределённое поведение программы и неопределённое поведение компиллятора. Первое, в данном случае, меня мало интересует, но если это оказалось так важно для общественности:

void func ( signed char indx ) { buf [ indx ] ++ ; }

Устроит? Думаешь что-нибудь изменилось, кроме того, что добавился один movwf в начале? Может из-за этого поведение данной функции стало более определённым чем ранее?

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Thu Mar 31 2005 08:15, Dima Orlov wrote to Alexander Golov:

...

DO> Вобщем напишу им в ближайшее время.

У-гу.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Thu Mar 31 2005 15:29, Alex Mogilnikov wrote to Alexander Golov:

...

AM> Кстати, что должно получиться в результате выполнения такой функции:

AM> void func() AM> { AM> signed char indx ; AM> buf [ indx ] ++ ; AM> }

Она предназначена не для выполнения, а для демонстрации некорректной работы компилятора, я же об это раньше прямо сказал. Тебе непременно хочется увидеть реальный код в котором я напоролся на данный баг? Была вот такая функция, перемещающая байт из кольцевого буфера UART'а в выходной буфер:

return ( Comm_Out [ Comm_Out_Ptr ++ ] = Comm_Buf [ Comm_Decd_Ptr ++ ]) ;

Мне понадобилось прооптимизировать код в прерываниях, используя специальную фичу PIC18, позволяющую индексно адресоваться к указателю, причём индекс при этом интерпретируется как число со знаком. Т.к. буферы кольцевые, размером 256 байт, проблема должна была легко решаться, путём использования базы буферов

+0x80. Асмовый код в прерываниях я исправил без проблем, а сишный решил заставить работать в нужном режиме объявив индексы (глобальные переменные) как signed char и добавив смещения:

return ( Comm_Out [ 0x80 + Comm_Out_Ptr ++ ] = Comm_Buf [ 0x80 + Comm_Decd_Ptr ++ ]) ;

Только связь вдруг пропала, а изучение кода показало, что там фигня.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Fri Apr 01 2005 20:17, Alex Mogilnikov wrote to Alexander Golov:

...

AM>>> Кстати, что должно получиться в результате выполнения такой AM>>> функции:

AM>>> void func() AM>>> { AM>>> signed char indx ; AM>>> buf [ indx ] ++ ; AM>>> }

AG>> Она предназначена не для выполнения, а для демонстрации некорректной AG>> работы компилятора, я же об это раньше прямо сказал.

AM> Из первого твоего письма я понял (возможно, неправильно), что AM> претензия к компилятору заключается в том, что инкрементируется не тот AM> элемент массива, который должен.

В общем можно и так сказать.

AM> И в качестве примера приводится код, AM> инкрементирующий indeterminated элемент массива. Компилятор для такой AM> функции мог например сгенерить код, всегда инкрементирующий нулевой AM> элемент.

Нет, он всё делал как надо, вычислял сумму адреса buf и значения indx, только он почему-то забывал, что indx -- число со знаком и расширение его до 16 разрядов простым присвоением нуля старшему байту некорректно; если знак отрицательный там должно быть 255.

AM> Или, скажем, всегда 44-й. И был бы прав.

В реальности все компиляторы на которых я это попробовал дали вполне ожидаемый результат.

Александр Голов, Москва, snipped-for-privacy@mail.ru