А может это самое "бла...бла" было такое длиное, что не влезало в 10 байт? А когда разместилось как static, может sprintf и залезало на верхнего соседа массива, но тот был того же толка, - временная переменная (что заявленый стиль программирования позволяет предположить), - которая стерпела вторжение. Даже с пониманием того, что компилятор не безгрешен по определению, следовало бы поискать ошибки сначала у себя, прежде чем бросаться в крайности. Конечно, каждый пишет, как хочет, и окончательным критерием истины является только одно - работает программа как надо, или нет, - но я бы позволил себе дать дружеский совет пересмотреть стиль программирования.

Ну понятно почему: что-то не так делаете. Неправильно их готовите...

На счет ошибок - я уже показывал этот пример другим. Никто ошибок не обнаружил. Так что вряд ли. Хотя опять же такое было в ранних версиях.
За это время и библиотеки могли поминяться и и еще что то. У меня щас времени нет перепроверять. Хочеш сам попробуй. А потом сообщиш о результатах.



Ну не 10 может 20 яж так к примеру. То что 32 бита занимают 10 символов+0+(возможно)знак я вроде как считать умею.
Мы здесь чего обсуждаем то? Разве не то кто с какими проблеммами сталкивался при оптимизации?
И от ошибок никто не застрахован. Все может быть.

Короче я все рассказал что вспомнил. Всем пока.

Сообщение отредактировал vlad_new - May 31 2012, 14:47

Уверен, что косяк у вас в коде. Довольно часто использовал подобные конструкции на разных уровнях оптимизации, никогда проблем не было.
Думаю, что обьяснение данное выше KnightIgor довольно точно описывает причину происходящего.

С Кейлом знаком еще по 51 семейству, еще тогда были проблемы с локальными переменными, если их передавать в функции (при чем в свои, а не в sprintf) и не обозвать static. Для arm аналогично, будет время покопаю этот момент.

А ничего так, что это два совершенно разных компилятора от разных производителей?

99.9% "ошибок компилятора" и "багов оптимизатора" - это косяки в коде. Обратному можно верить только при наличии примера в виде код + дизассемблер.

Я это к тому, что еще с тех пор взял за правило ставить static у локальных переменных в функциях, если они идут дальше.

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

Очень странная идея.
Зачем оно надо?

P.S. volatile не пробовали для локальных? Это хоть не так нелогично.

Это танцы с бубном. Так не интересно. Лучше докопаться до сути проблемы.

Вы заблуждаетесь, логика присутствует.
При static локальная переменная будет жить в глобальной области памяти, а не на стеке. И именно поэтому проблемы исчезали.

PS: На работе попробовал по памяти набросать код, который вызывал когда-то проблемы (чтобы осмысленно глянуть в дизассемблер) - в функции локальный массив или указатель передается дальше. Но увы, всё работает, как надо при любой оптимизации. =) Помню, когда в последний раз такое случалось, я перенес аналогичный код в iar'овский компилятор - там без static работало. И т.к. это был не первый случай, то старался больше не рисковать и ставил static у локальных указателей и массивов, если они идут дальше (реентерабельность не требовалась). Прочитав эту тему по диагонали и заметив знакомую проблему, удивился что уважаемый aaarrr очень уверенно говорит, что дело не в компиляторе. Может оно и так, но помимо меня как минимум еще двое испытывают похожие проблемы.

Ну какая-то логика конечно присутствует, если программа всё-таки работает.



Зачем переменной "жить в глобальной области памяти"? Локальная переменная должна жить в стеке (за исключением особых случаев).
Вопрос в том, почему такие проблемы вообще возникают. Что-то делаете не так.
Согласен с мнением scifi



Каким-то образом вам удалось заткнуть проблему (с помощью static), но не факт что не вылезет где-нибудь в другом месте.



Если реентерабельность не требуется, то как бы и ладно, если по другому никак.
А как потребуется?
Или как такое будет работать в программе с ОС? Понятно что никак не будет.



aaarrr видимо прав на 100 %. Если у него таких проблем не возникает, то что-то эти "ещё двое" делают не правильно и дело не в компиляторе. Вообще за последние несколько лет не встречал чтобы дело было в компиляторе (правда я с iar работаю), 99% что виноват программист, ну и может доли процента можно оставить на глюки компилятора.

Речь шла о том, что помогло решить проблему и что дает static у локальных переменных. Другое дело, что это костыль.


Так вроде мы и не из этих, которые свои косяки валят на компилятор, кристалл или фазу луны. Увы, воспроизвести "по заказу" не могу, поэтому добавляю тему в закладки - и как только, так сразу.

Чтобы поддержать тему, расскажу о реальном замеченном глюке оптимизации:
Компилятор игнорировал #pragma arm section при автоинлайне. То есть встраивал функцию, для которой была определена конкретная секция, в тело другой, расположенной по умолчанию.