• State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 22 subscribers
  • Views 7825 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Lx51 "Data Type Different" Warnings ?

Andrew E. Kalman

Hello.

I have a project that links to a library I created using the C51 toolset.

If I build it using BL51, everything's cool. If I build it with Lx51, I get warnings like this:

*** WARNING L25: DATA TYPES DIFFERENT
    SYMBOL:  _FnName
    MODULE:  .\main.obj (MAIN)
though the application appears to work just fine in the simulator.

If I build the project with source files only (i.e. I compile the modules that are normally in the library, and I don't link to the library) then everything works under BL51 and Lx51.

So, what can I do to enable me to build projects using Lx51 and my libraries, and avoid these "Data Type Different" Warnings?

Parents
  • 0 in reply to Andrew E. Kalman

    OK, I think I solved this particular problem -- looks like LIBX51.EXE is required to build libraries for C51+OMF2 directive or CX51.

    This wasn't entirely clear from the manual, but in hindsight I guess it makes sense.

    P.S. There's a typo on page 17 of the Cx51 Manual -- 2nd-to-last line should read "... C51 compiler that is designed for the new Philips ..."

    Regards,

Reply
  • 0 in reply to Andrew E. Kalman

    OK, I think I solved this particular problem -- looks like LIBX51.EXE is required to build libraries for C51+OMF2 directive or CX51.

    This wasn't entirely clear from the manual, but in hindsight I guess it makes sense.

    P.S. There's a typo on page 17 of the Cx51 Manual -- 2nd-to-last line should read "... C51 compiler that is designed for the new Philips ..."

    Regards,

Children
  • 0 in reply to Andrew E. Kalman

    OK, I have solved the original problem.

    Certain compilers (which shall remain nameless, but are not Keil competitors because they serve a different target market) require that external array references include the size of the array in them (!), e.g.:

    extern OStypeEcb OSecbArea[5];
    instead of the more common (and more desireable, to be sure)
    extern OStypeEcb OSecbArea[];
    which is the way Keil C51 works.

    Anyway, this declaration was causing problems, because the libraries had been compiled for a particular size array (e.g. 5), yet the local module (in source code) that actually defined the array and therefore overrode what was in the library was set to a different size (e.g. 1) in order to minimize RAM requirements. Once the numbers matched, then all problems disappeared.

    So, the lesson is to always use the more general form of the external declaration 
    extern type ArrayName[];
    and you'll avoid all of these problems.

    Regards,

  • 0 in reply to Andrew E. Kalman

    Does this compiler do array bounds checking?
    I s'pose that might be a reason for it to want the size

  • 0 in reply to Andy Neil

    If my compiler did array bounds checking, I would shoot it!

    I use negative array indexing all the time for useful kinds of stuff.

    Jon

  • 0 in reply to Andy Neil

    Andrew asked "Does this compiler do array bounds checking?"

    Probably. Our arrays in question are arrays of struct, and all access is through pointers.

    Does the ANSI C standard say anything about this issue (how to declare extern arrays)?