Stupid Warnings from DS 2.2.1

IoT Modules Development tools
1

Since upgrading to DS 2.2.1, I an getting floods of warnings like

But:

And:

So ‘u32’ is just a synonym for ‘unsigned int’ anyhow :exclamation: :unamused:

How to suppress these spurious “warnings” :question:

2

Which toolchain are you using?
In the problem view, is this warning highlighted as a “Semantic Problem” or “C/C++ Problem”?

3

SW Suite Package 2.35.0
ARM EABI GCC

“C/C++ Problem”

4

Did you change anything else that just upgrading DS?
If this warning is raised by the compiler (BTW, can you confirm that by taking a look at the build console?), I can’t imagine a reason why you didn’t get it before, with the same packages/toolchain configuration…

Please could you provide a code snippet to reproduce the behavior?

5

I think it was with the DS upgrade that I switched to EABI instead of ELF?

Yes, it is

I’ll have a go…

6

Hello awneil,

Do you find a solution to suppress the warning ?

The solution for _ARM_EABI_GCC compiler:

u32 uiValue;
	ascii szLog[512];

	uiValue = 0xFF;
	wm_sprintf(szLog, "uiValue: %lu", uiValue);

The solution for _ARM_ELF_GCC compiler:

u32 uiValue;
	ascii szLog[512];

	uiValue = 0xFF;
	wm_sprintf(szLog, "uiValue: %u", uiValue);

The difference between them is the presence or not of the l sub-specifier.

For both compilers:

typedef uint32_t  u32;

But for _ARM_EABI_GCC compiler:

typedef unsigned long uint32_t;

So printf family functions require the l sub-specifier (l for long).

and for _ARM_ELF_GCC compiler:

typedef unsigned int		uint32_t;

In this case, no need to add the l sub-specifier.

Is there any solution to manage in a simple way the same code with no warning for the two compilers ?

Thanks,
Marc

7

I’m looking for a good way to disable those warnings too…

I’ve just started importing old projects that have previously used ADS with the ancient toolchain into Developer Studio.

Since I have to maintain compatibility with Visual Studio and ADS, changing the format specifiers is not a viable solution.

(All of our normal work is done in Visual Studio with code analysis done by VS and PC-Lint, with target build done using ancient toolchain and ADS compiler in virtual machine and now looking to add target build with DS for newer firmware targets)

8

No, but I think I found the reason for them.

For historical reasons, I had my own standard type definitions. These were equivalent to the ADL ones, but not identical.

So the answer would be for me to adjust my definitions.

9

I don’t have my own definitions for the same types, but the warnings still show up…

Probably Eclipse that is unable to see that it is the same underlying type…

10

Actually… Going from:

format '%2X' expects type 'unsigned int *', but argument 3 has type 'u32 *'	***.c	/***/src	line 2081	C/C++ Problem

Doing Open Declaration on u32, then on uint32_t, in stdint.h it gets a hit on:

#if __have_long32
typedef signed long int32_t;
typedef unsigned long uint32_t;
#define __int32_t_defined 1

So it is tying unsigned long to u32 and not unsigned int…

Is it a GCC thing to do it that way??

11

It seems there is a “standard/portable” way of handling uint32_t and similar types together with *printf…

Example:

u32 var=0;
sprintf(buffer,"%"PRIu32,var);

Instead of:

u32 var=0;
sprintf(buffer,"%u",var);

PRIu32 and other similar macros are defined in inttypes.h, and if you’re a Visual Studio user like me, you’ll need to find a visual studio compatible version of that header.

Unfortunately, Sierra’s wm_types.h doesn’t include <inttypes.h> and instead goes for <stdint.h> which is included from <inttypes.h>, so it’s necessary to either change wm_types.h or to handle it some other way…

Edit: It’s already necessary for me to edit wm_types.h because wm_types.h uses _intX rather than __intX for visual studio, so more edits is no problem for me.
It’s just a lot of work to change from %u, %d, etc. to "PRIu32, etc. just to get rid of stupid warnings.

12

Is anyone aware of a workaround for this problem? We have just started working with ARM_EABI_GCC, but have to continue supporting ARM_ELF_GCC and are being flooded with warning of the flavour: “format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘u32’”. We are unwilling to hack on wm_types.h or stdint.h. Our own types are an option, but one we would like to avoid as the code-base is large (not reeeeally a problem) and somebody on the team is GOING to stuff this change up in the future (a serious problem).

Any suggestions?