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.
"(void *) is defined to be able to hold all data pointers, but not function pointers."
Could you provide a reference to that one.
I was just about to ask the same thing!
I've had a quick look through my copy of ISO/IEC 9899:1990 and didn't see it - but the text can be very opaque...
There is a rule that "A pointer to void may be converted to or from a pointer to any incomplete or object type." So you may typecast between a void pointer and some other data type.
But when an architectire have __far, __near, __code, __data, __base etc, it isn't automagically possible to store all pointers as a char pointer (or as a void pointer).
This means that void* isn't an automagic solution that can handle anything for real platforms even if the standard somehow implies this. It may be compatible with a function pointer. But what if you have a memory model where code is large and data is small - so a function pointer may need a larger size than a char* pointer. For old 16-bit x86 code, char* is byte-aligned byt in "compact" memory model it is 16 bit large while a function pointer is 32-bit large.
This is a bit similar to how the standard concludes that an integer may always be converted to a pointer, but the result of that pointer is implementation-defined. It may produce an undefined result because the integer couldn't store all information needed for a pointer.
The standard (§6.3.2.3 point 8) says that a function pointer can be converted to another function pointer and then be converted back again.
But the standard doesn't go any further. You don't have any guarantee that a convertion between a function pointer and a char/void pointer will work.
(Since I've been challenged to quote chapter and verse: that rule quoted by Per is actually clause 6.3.2.3, paragraph 1 of C99).
And the clue to the case at hand is that a function pointer is not a "pointer to any incomplete or object type" (see C99 6.2.5, paragraph 1).
So conversion between function pointers and (void *) is not specified by any rule of the standard, which puts you into undefined behaviour land by default.
The C programming languages supports Harvard architecures, and that means code and data pointers are assumed to be fundamentally different things. There is no allowed way to convert from one to the other.