Difference in uint32_t between Redlib and newlib causes Eclipse CDT code analyser to misbehave

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by OldManVimes on Sat Feb 21 03:35:40 MST 2015
Hi support,

My LPCXpresso (7.4.0) workspace contains 2 MCU projects. One using Redlib (LPC1200) and the other using newlib (LPC1700) (not NewLibNano).
These projects have several source files with the same name (not sure whether this is relevant, but it does not hurt to mention).

In Redlib, uint32_t is an unsigned int (defined in stdint.h)
In Newlib, uint32_t is a __UINT32_TYPE__ which (according to the CDT) expands to "long unsinged int" (defined in _default_types.h). I guess __UINT32_TYPE__ is a compiler built-in macro.

Since we are dealing with a 32-bit CPU, the binary difference between the two is zero. So far so good.

In my Redlib project a printf of a uint32_t looks like:
uint32_t foo = 42; // unsigned int
printf ("foo: %u\n", foo);

In newlib it is:
uint32_t foo = 42; // long unsigned int
printf ("foo: %lu\n", foo);

There are 2 issues:
1. This is annoying since it is essentially the same source file, but the format string must differ because there is a type mismatch between the two library sets.
2. The eclipse code analyser (so not the compiler!) gets confused and starts complaining about the format strings.

I can solve problem 1 by ditching Redlib for Newlib nano, or by using those horrible PRIu32 style macros, but I would prefer not to.
Problem 2 is really weird, because I can get it to behave again by rebuilding the index. However the required activities are vague. Sometimes I can get it to work, and other times I cannot.

So here are my questions:
1. Why are there differences in the types? Can you (provide an option to) harmonize them in a future release?
2. Why does the CDT indexer / code analyser get confused and what can I do to (short of disabling the CODAN setting) prevent that from happening?

Kind regards,