With dynamic loading enabled the function ctk_textentry_input_null() lives in the...
commitea5056d0c1a45be968517c172595ccef08281541
authoroliverschmidt <oliverschmidt>
Sat, 28 Feb 2009 10:43:30 +0000 (28 10:43 +0000)
committeroliverschmidt <oliverschmidt>
Sat, 28 Feb 2009 10:43:30 +0000 (28 10:43 +0000)
tree07d444aae9a367cde3945d38150572996d70eccb
parentab1c7f11f38b7d417d1f4b1a5e44ce8da5036628
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
core/ctk/ctk.h