• State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 21 subscribers
  • Views 4225 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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

Change list for RealView Compilation Tools available?

Michael RigbyJones

The Release_Notes.htm file in the ARM compiler gives an overview of changes made between MDK-ARM versions, but is there somewhere I can find out exactly what bug fixes/improvements have been made to the RealView compiler itself?

The behaviour of the compiler has changed between MDK-ARM versions 4.03a and 4.10, which is not surprising since the compiler is a new version in this release. However, this has resulted in some code developed on 4.10 (which compiles with no warnings) to fail with an error during compilation on 4.03a. Specifically I have a function which accepts a pointer to void, and am passing a function pointer to it.

I can make the code compile on both versions with some casting, but I would like to be able to see if this issue is known and if there are other issues we should be wary of.

Parents
  • 0 in reply to Cactus Michael

    §6.3.2.3 item 1 is a reference. I did mention it earlier, even if I didn't specify the paragraph. It specifically limits the applicability of void pointer conversions to incomplete and object types. A function isn't incomplete. And it isn't an object. See §6.2.5 for types. But paragraph 20 have an interesting sentence: "Any number of derived types can be constructed from the object, function, and incomplete types, [...]". Notice how "function" is listed separately from "object" or "incomplete"?

    And §6.3.2.3 item 8 (which I quoted earlier) give you the promise regarding function pointers - you may type cast one function pointer to another, and then back. No promise about going from function pointer to data pointer or the reverse.

    And item 5 and 6 that takes care of conversion between integers and pointers specifically mentions that while the conversions are allowed, the result is implementation specific. So you can't rely on them to do function pointer -> integer -> function pointer with any promise of ending up with a correct function pointer except for the special case of null pointers.

    If the OP isn't busy with typecasting NULL pointers, then he is busy trying to perform type casts that are not promised to give a defined behaviour by the standard.

Reply
  • 0 in reply to Cactus Michael

    §6.3.2.3 item 1 is a reference. I did mention it earlier, even if I didn't specify the paragraph. It specifically limits the applicability of void pointer conversions to incomplete and object types. A function isn't incomplete. And it isn't an object. See §6.2.5 for types. But paragraph 20 have an interesting sentence: "Any number of derived types can be constructed from the object, function, and incomplete types, [...]". Notice how "function" is listed separately from "object" or "incomplete"?

    And §6.3.2.3 item 8 (which I quoted earlier) give you the promise regarding function pointers - you may type cast one function pointer to another, and then back. No promise about going from function pointer to data pointer or the reverse.

    And item 5 and 6 that takes care of conversion between integers and pointers specifically mentions that while the conversions are allowed, the result is implementation specific. So you can't rely on them to do function pointer -> integer -> function pointer with any promise of ending up with a correct function pointer except for the special case of null pointers.

    If the OP isn't busy with typecasting NULL pointers, then he is busy trying to perform type casts that are not promised to give a defined behaviour by the standard.

Children