IAR 5.40.0.51500 баг в sprintf @ lpc1114/CM0 Опции

[GetSmart]

Непонятный баг в виде выпадения в HardFault из sprintf при выводе форматированного float, причём в некоторых случаях. Юзал эту версию ИАРа вместе со sprintf для LPC1768 и ни на какие грабли не попадал. Стек проверял, его достаточно, оптимизация никак не влияет. Простенький кастрированный проект прилагаю для LPC1114 (без кварца) можно потестить. Прочитал все исправленные баги в версии 6.30 и не нашёл ничего об исправленном sprintf. Хотя тот же код в 6.30 не зависает, но проверил наспех. Поэтому самому интересно в чём косяк и исправлен ли он в новых версиях ИАРа.

Код

    sprintf((char *)&buf, "started\15\12");
    sendBuf(&buf[0]);

    for (uInt i=0; i<sizeof(buf); ++i) buf[i] = 0xeb;
    float freq = 82.6046981;
    sprint_flag = 10;
    sprintf((char *)&buf, "freq1=%1.5f\15\12", freq);           // <------- тут происходит падение на HardFault
    sprint_flag = 0;
    sendBuf(&buf[0]);

    sprintf((char *)&buf, "ended\15\12");
    sendBuf(&buf[0]);

Регистры на картинке взяты из режима исключения HardFault, на котором стоит бесконечный цикл.

Эскизы прикрепленных изображений

 

[aaarrr]

Стоп, это ж M0, а он в принципе не умеет unaligned access делать.
В опциях точно M0 стоит? Если да, тогда баг однозначно.

Т.е. во всех функциях sprintf в качестве 1-го аргумента следует указывать (char *)buf или (char *)&buf[0], а не (char *)&buf
А покуда это не сделано, искать какие-то иные ошибки в его коде неразумно.

В случае массива buf и &buf - это одно и то же.

[GetSmart]

Стоп, это ж M0, а он в принципе не умеет unaligned access делать.
В опциях точно M0 стоит? Если да, тогда баг однозначно.

Да, точно М0.
Мне во всём этом интересно, что баг этот зависит от стечения многих нюансов. Например формата %1.5 в сочетании с float. Поэтому и приводить к double смысла нет. Там с тем значением плавучки идёт округление двух чисел и результат сокращается до 4 знаков после запятой. Может это что-то значит. Вообще, хотелось бы выяснить задокументирован этот баг или нет. И связь с новыми версиями компиляторов.

Почему, кстати, у многих местных модераторов есть такая привычка делать несущественные замечания. Зелтиго, Резидент, Ксюша, все страдают этим. Зелтиго в отсутствие аргументов вообще любит/л цепляться за while(1). Если конструктивно нечего сказать, то лучше промолчать. ИМХО это "болезнь", корелирующая с некой административной профнепригодностью.

В том конкретном случае &buf и &buf[0] абсолютно одинаковый код дают, т.к. буфер статический с абсолютным адресом. Меняй, не меняй каша слаще не станет.