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.
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.
then why does the latest compiler produce perfectly working code with no warnings?
Wrong question. Once your code invokes undefined behaviour (which this one does) compilers are allowed to do whatever the heck they want with it. There is literally no limit to what is allowed to happen. Including "works as expected, even though that expectation was unjustified".
And since you didn't violate any of the (rather few) rules where the C Standard requires a diagnostic to be output by the compiler, you're not even entitled to a warning.
I'll take that as a no then.
On what grounds do you draw that conclusion?
By virtue of the fact that you have not provided one - Duh!
the fact that you have not provided one
So the fact that I did provide one, about two hours before you decided I hadn't, must exist entirely in my imagination only, right? Duh! yourself!
I see opinion but no reference.
§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.
Thanks Per,
I wasn't questioning you or your previous posts.
As is normal, they were very complete and very helpful (and very positive).
And it really would have killed you to say exactly that right away, wouldn't it? Instead of just making unsubstantiated accusations, that is?
Oh, and just to possibly turn this part of the discussion in a constructive direction: how, exactly, is "C99 3.2.5 paragraph 1" not a reference?
I could hardly have said it before it became apparent.
Looking through the times of the posts, it seems that:
either you did not initially post a response containing a reference,
or for some reason your initial post containing a reference was (and still is) invisible when I view the web page.
Fortunately, Per's post is visible.
Ah. I see it now.
I retract my previous comments.