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.
Could you please provide a reference for your assertion that a void pointer can not hold the address of a function?
If your assertion is correct and passing a function pointer to a (const void *) argument is not permitted, then why does the latest compiler produce perfectly working code with no warnings?
Irrespective, this doesn't answer my question; is a list of changes/improvements/bug fixes for the Realview compiler versions available?
Where is Jack Sprat when you need him!
"...fail with an error during compilation on 4.03a."
Michael,
Out of interest, what error is reported?
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.
You may want to look at the ARM website to see if there are any details on the updates there.
I don't have the time to look, but this might be a useful start:
www.arm.com/.../rvds-updates-and-patches.php
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).
Not really. There are some differences between MDK armcc and RVDS armcc. In particular you won't typically find the same build numbers, which renders the RVDS changelist rather useless for tracking MDK changes. But I don't have a better idea either...
-- Marcus http://www.doulos.com/arm/
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.
Thank you, that is exactly the information I was after.
And thank you Per for a clear, concise and non-judgemental explanation of the issue. Hopefully this thread will be useful for others as well.
I think there is still a PC in our lab that hasn't been update with the latest compiler version, if so I will build again and make a note of the error code, but the error was about a non-compatible argument type, which certainly fits in with the references provided in this thread.