Code (Salvo) compiles fine under Cx51, but results in a WARNING L25: DATA TYPES DIFFERENT message when compiled under C-ARM. This only affects pointers (they're all pointers to structs), where they're declared in one module (mem.c) and accessed in another (init.c) via extern declarations. Compile options on both files are the same, no other issues. I've seen (and resolved) this sort of problem before in Cx51 when there was a mismatch between a source file and a library I had generated. In this case, there's just two source files involved, so I'm a bit stumped. Can anyone help? Thanks,
"where they're declared in one module (mem.c) and accessed in another (init.c) via extern declarations." Just to get this precise, you mean they're defined in mem.c, and accessed via extern declarations in init.c? You could try removing the extern declarations from init.c and putting them into, say, mem.h instead - then #include mem.h in both mem.c and init.c. That way, the compiler gets to "see" both the declarations and the definitions when it compiles mem.c - and will be able to warn of any mismatches
Hi Andy. Thanks for your reply. Sorry for the inaccuracy -- yes, they're defined in mem.c, and accessed via external declarations in the Salvo header file(s). As this exact same code compiles fine under Cx51 (and many other compilers that check for type mismatches), I don't think that a lack of extern consistency is the problem. Rather, there seems to be something more fundamental / unique to the C-ARM compiler going on here ... Any other ideas?
Here's another oddity .. even though the pointers are defined in mem.c, and accessed via extern declarations from other files (e.g. init.c), the .map file lists each pointer as MODULE: mem.obj and DEFINED: init.obj. I hope that this doesn't mean that LA thinks these objects are defined in init.obj ...
More info ... Adding a second file (sched.c) to the project that also acceses the pointers via external declarations causes LA to crash (100% consistent), yet uVision3 survives, and the build result is a build with 0 errors and 0 warnings ... Methinks this is a toolset bug ...
"I don't think that a lack of extern consistency is the problem." Why not just give it a try & find out for sure! There can be many subtleties on which compilers differ - maybe you've just found one? I often recommend that people should build on multiple compilers for exactly this reason!
Note that the CARM Library is translated with 'char' configured as 'unsigned char'. Maybe this is the reason for the type mismatches.
Thanks for the replies -- all Salvo types are explicit, so I don't think that's a problem. But I readily admit that I don't fully understand / appreciate how the CARM's library settings will affect Salvo. I've sent a set of example projects (Cx51+uVision2, DK-ARM+uVision3) to RK on Germany ... they illustrate how, when using the same code, the warnings only occur in DK-ARM, and only with pointers to structs. We'll see what comes back ... BTW, the LA crash was apparently due to additional leftover project files in the same directory. Once I deleted them, it stopped crashing.
Update -- these problems are fixed in CARM v1.4. Now I'm facing a DATA TYPES DIFFERENT between an assembly module (Thumb mode) and mem.obj -- but that's probably easy to fix. Thanks to all!
Update -- this DATA TYPES DIFFERENT problem persists with some combinations of assembly and source code -- I'm working with Keil to resolve them.
Update: This has now been fixed by Keil ... I suspect it will be included in the next CARM release ...