Какие опции задать компилятору, что бы тип uint32_t соответствовал типу unsigned int, а не unsigned long ?

В данный момент тип uint32_t приводит по ссылке в

да, есть варнинг



в таком варианте сразу два предупреждения



повторюсь, почему я создал тему: раньше пользовался кейлом, и там

и никаких возражений на счет printf("%i\n",i); у компилятора не возникало

сейчас перешел на бесплатный компилятор, в котором
+ варнинг.
это то меня и смутило. причем в кейле определение uint32_t статично, а в бесплатном компиляторе определение зависит от дифайна #if __have_long32 который в свою очередь зависит от #elif __STDINT_EXP(LONG_MAX) == 0x7fffffff && !defined(__SPU__) и тд
я подумал, может компилятору ключей каких то нехватает, что бы uint32_t определился как в кейле, для этого должно выполниться условия препроцессора




спасибо кэп

на запись printf("%" PRIu32 "\n",i);



Сообщение отредактировал k000858 - Jan 22 2014, 03:28

Вы читайте все ответы
Эти спецификаторы определены в файле inttypes.h

Если пишете на C++, то надо еще предопределить символ __STDC_FORMAT_MACROS, например через CPPFLAGS += -D__STDC_FORMAT_MACROS в makefile.

а, точняк. забыл включить inttypes.h

в этом варианте варнинга нет

алелуя

варнинга нет, это хорошо )
вы уж простите за мою доё..сть, назойливость, но меня больше интересовал вопрос "как сделать что б было как в кейле" а не "как убрать варнинг" )))
ну т.е. какие ключи задать компилятору что бы uint32_t определялся как в кейле т.к. определения в stdint.h зависят от незнакомых для меня макроопределений

И я таки отвечал на этот вопрос выше. Отвечу снова: подрихтуйте файл stdint.h.

хотелось бы подрихтовать библиотеку с помощью макроопределений (они ведь там не просто так для красоты)
заодно понять как, где и зачем они выбираются

Не вздумайте править библиотечные хидеры stdint.h, т.к. на вашей машине проект будет работать как положено, а на другой - нет. Используйте макроопределения.

вот я как раз через макроопределения и хотел настроить нужные мне типы данных
однако немного не понимаю, откуда берутся все эти

подозреваю, что от настроек компилятора

Вот сейчас столкнулся с аналогичными варнингами при сборке LwIP


сс.h

Т.е. компилятор пишет варнинги при использовании unsigned long в качестве unsigned int, хотя в ARM типы одинаковы.

компилятор https://launchpad.net/gcc-arm-embedded

предупреждения перестают писаться при отключении -Wall, но тогда вообще никаких предупреждений нет.
подрихтовывать stdint.h не вариант...

У вас ошибка в файле cc.h: раз уж u32_t - это unsigned long, то и формат для printf должен быть "%lu". И вообще, почитайте про printf.

Типы разные. Они имеют одинаковый размер для ARM, это да. Но типы разные. Так же как и соловьев и болты можно измерять в штуках, но путать не стоит. А предупреждение, вероятно, выдается для того, чтобы вылизанный исходник не стал выдавать море ошибок при попытке скомпилировать для другой платформы.

файл сс.h взят от ST (пример проекта для Keil, IAR, TrueStudio и тд)
этот же проект в кейле компилируется без каких либо варнингов
но там и uint32_t unsigned int

только в бесплатной версии eclipse + GNU Tools for ARM Embedded Processors такая непонятка с типами...

ну понятно, что можно в cc.h подправить #define U32_F "u" на #define U32_F "lu"...но может есть способ принудительно компилятору определить uint32_t как в большенстве компиляторов?
определяется тип макросом #if __STDINT_EXP(LONG_MAX) > 0x7fffffff а откуда что берется не понятно.

так же наверняка можно компилятор с помощью некой опции попросить не беспокоиться о несоответствии unsigned int и unsigned long (ведь тот же кейл не дергается..)

Ну вот и найдена причина: ST славен своим индусским говнокодом.


Сомневаюсь, что есть такой способ. А даже если бы и был, это было бы скорее вредно, чем полезно. Потому что эти предупреждения реально указывают на ошибки в коде (да, безобидные ошибки, но это до поры до времени). Не надо принудительно давить предупреждения, надо исправлять сами ошибки.


Это скорее недоработка кейла. Но иметь возможность отключать конкретное предупреждение было бы удобно и оправдано в ряде случаев, это да.