Hacker News Reader

Comment by copx | Hacker News Reader

This could be made massively less ugly and more readable by typedef'ing the function pointer types by the way. Then one could just write:

  case 13: mv->val.f13 = (F13)func; break;

As a C programmer I got to say people in general don't use typedef for function pointer types often enough. The types are so ugly and verbose, they should be typedef'ed by default.

View on HN

I think the primary argument that I've heard against typedefing function pointers is you can end up obfuscating what is happening and end up making the code less readable/harder to maintain in the future.

This code could take advantage of the fact that the type is a union.

One can bend the rules of prim-and-proper well-defined ISO C just a little bit and assign to the simplest function pointer, taking advantage of all function pointers having the same representation on every machine known to mortal hacker, and all being overlaid by the union. Thus all the cases collapse down to this:

   mv->val.u.f0 = (void (*)(void)) func;

done. Now if this is 13 arguments, then strictly speaking, accessing mv->val.uf13 is not well-defined behavior. That's only going to be problem when it actually doesn't work, though. A big problem, then. :)

I can respect the author taking the trouble to avoid undefined behavior. Technically correct is the best kind of correct.

That sort of love affair with ISO gospel lands on the rocks as soon as your Lisp stuffs a couple of tag bits into a C pointer.

I look forwards to your pull request! One challenge you'll run into is that (as I recall) the Boehm GC linkage no longer works with newer versions of Boehm.

Reply on news.ycombinator.com