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.
Yes, I see what you mean regarding version numbers. Not ideal, but I can at least search to see if a specific issue has been noted/fixed.
If anyone is interested the actual error was:
const void * LDR_TranslateAddress(const void *addr); uint8_t MyFunc( void ); ((uint8_t (*)(void))LDR_TranslateAddress( MyFunc ))(); error: #167: argument of type "uint8_t (*)(void)" is incompatible with parameter of type "const void *"
This clearly ties in to the C standard. Whilst the behaviour is undefined in the standard and the compiler is free to do what it wants, it seems quite reasonable for the compiler to permit this on the targets where it will work.
I suppose a good follow on question is: "Is there a portable way to pass an arbitrary type of function pointer?"
IMHO, no, there isn't, because passing a function pointer as any other type than its own throws away information that you cannot do without if you're ever going to use that function pointer (see my other post about the consequences of C99 6.3.2.6 p8).
I.e. if you really want to pass a "generic function", it can't be just the pointer. You always need information about the type it originally had, too. And that information really had better be kept together with the pointer itself, in a struct. But then, once you've gone there, you no longer need function pointer casts:
typedef void (*t_func_void_of_void)(void); typedef uint8_t (*t_func_uint8_t_of_void)(void); /*expand as needed */ typedef struct generic_function_handle { enum { E_FUNC_VOID_OF_VOID, E_FUNC_UINT8_T_OF_VOID, /* expand as needed */ } f_type; union { t_func_void_of_void func_void_of_void; t_func_uint8_t_of_void func_uint8_t_of_void; /* expand as needed*/ } f_pointer; } generic_function_handle;