Re: [Nano-devel] function database handling

[Chris Allegretta]

Thank you for this suggestion bernd!  Looks like I was able to get
this done in less than a year after you made it :-)

Unfortunately this has the effect of increasing our binary size by
10%, at least on x86-64.  Having all those shorts instead of stub
functions to allow the key remapping may have bene ugly but it did
save memory.  Still it at least feels better to have the code this way
even if this implementation is not perfect.

On Sun, May 16, 2010 at 9:39 PM, bernd <address@hidden> wrote:
> Trying to figure out the design decision for tying up function-database
> entries using short integers, preceding something like 150 (!) lines of
> preprocessor macro definitions, I stumbled across the following comment.
>
> /* Since in ISO C you can't pass around function pointers
> anymore,
>  let's make some integer macros for function names, and then
> I
>  can go cut my wrists after writing the big switch
> statement
>  that will necessitate. */
>
> As I can only guess, what you were orignially trying to do, I might be
> completely wrong with my assumption.
>
> Nevertheless as far as I know contradictory to conversion of object
> pointers to function pointer types, passing function pointers should
> still be very much compliant to ISO C.
>
> Just in case you tried to pass your function pointer like shown in the
> following example, the ISO C forbidden part might not be the one you
> expected interpreting compiler warnings.
>
> #include <stdio.h>
>
> void lots_of_isoc_warnings (void* func)
> {
>  void (*function) () = func;
>  function ();
> }
>
> void hello_world (void)
> {
>  printf ("helo world.\n");
> }
>
> int main (void)
> {
>  lots_of_isoc_warnings (hello_world);
>
>  return 0;
> }
>
> Resultig compiler warnings should be due to the fact that void* doesn't
> denote a pointer to anything, but a pointer to any object.
> So contradictory to the assumption passing function pointers might raise
> the resulting warnings, the exact opposit is true.
>
> By a construction like the one shown in the example above, you aren't
> passing any function pointer at all!
>
> As required by lots_of_isoc_warnings prototype taking an argument of
> type void*, just before passing it, the function pointer to hello_world
> is implicitly and in ISO C's sense illegaly converted from function
> pointer to object pointer.
> The explicit typecast in lots_of_isoc_warnings converting it back from
> object pointer to function pointer is likewise forbidden in ISO C and
> thus responsible for another compiler warning.
>
> Nevertheless none of the two above mentioned issues has anything to do
> with ISO C forbidding function pointers as arguments in function calls.
>
> If the prototype of the called function doesn't expect an object
> pointer, but a function pointer as its argument, no implicit an in ISO
> C's sense illegal conversion to object pointer type will be performed
> and everything should work as expected.
>
> The following example - (almost) no pun on another bunch of about 150
> lines of code remapping short int identifiers to function calls intended
> - should clarify  what I mean.
>
> Compile with -Wall -pedantic to see for yourself.
>
> #include <stdio.h>
>
> void no_need_to_iso_you_harder ( void(*func)(void) )
> {
>  func ();
> }
>
> void hello_world (void)
> {
>  printf ("helo world.\n");
> }
>
> int main (void)
> {
>  no_need_to_iso_you_harder (hello_world);
>
>  return 0;
> }
>
> Just in case you haven't already cut your wrists, as threatened in the
> above cited comment, I'd like to beg you to change function call
> handling in nano the way it seemingly was intended originally.
>
> Additional to saving about 300 lines of code, this would also make code
> a lot more readable and small customizations a lot easier to perform.
>
>
> The most important words at last: Thank you for sharing such a
> masterpiece of software with the community.
>
> Even in hard times generosity and philantropy of people like you
> contributing to the free software movement never made me stop believing
> in the goodness of mankind. Thank you so much especially for this.
>
>
>
> Best regards
>  Bernd.
>
>
>
> _______________________________________________
> Nano-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/nano-devel
>