With dynamic loading enabled the function ctk_textentry_input_null() lives in the persistent core while the macro CTK_TEXTENTRY() is typically used in loadable modules. So ctk_textentry_input_null() needs to be dynamically resolved.

On Win32 dynamic resolving isn't done by patching the dynamically loaded segments. Rather the code generated by the compiler for accessing symbols declared with __declspec(dllimport) is implicitly modified to actually go through pointer dereferenciations. The dynamic linker only initializes this pointers.

But with the symbol ctk_textentry_input_null becoming a pointer to a function it isn't a constant anymore and so it can't be used as initializer element - and thus breaking CTK_TEXTENTRY().

So the only viable solution seems to stick to the inversally available NULL pointer on Win32. But if there's an ugly #ifdef <platform> necessary anyway than it seems resonable to classify ctk_textentry_input_null as the special case and therefore use #ifdef SDCC:
- It saves some bytes on all non-SDCC platforms
- Is matches the exsisting inline documentation

core/ctk/ctk.c

@@ -44,7 +44,7 @@
  *
  * This file is part of the Contiki operating system.
  *
- * $Id: ctk.c,v 1.23 2009/02/27 14:42:49 oliverschmidt Exp $
+ * $Id: ctk.c,v 1.24 2009/02/28 10:43:30 oliverschmidt Exp $
  *
  */
 
@@ -1165,6 +1165,7 @@ activate(CC_REGISTER_ARG struct ctk_widget *w)
   return REDRAW_NONE;
 }
 /*---------------------------------------------------------------------------*/
+#ifdef SDCC
 /* Dummy function that we define to keep sdcc happy - with sdcc,
    function pointers cannot be NULL. ctk_textentry_input is typedef'd
    in ctk/ctk.h, hence the strange-looking function signature. */
@@ -1173,6 +1174,7 @@ ctk_textentry_input_null(ctk_arch_key_t c, struct ctk_textentry *t)
 {
   return 0;
 }
+#endif /* SDCC */
 /*---------------------------------------------------------------------------*/
 static void CC_FASTCALL
 textentry_input(ctk_arch_key_t c, CC_REGISTER_ARG struct ctk_textentry *t)