Pointers to functions

[Hank Dietz]

In article <7811 at tut.cis.ohio-state.edu>, mills-cl at pike.cis.ohio-state.edu (christopher mills) writes:
> the pointer arithmetic part and wondered what C does when you try to do
> pointer arithmetic on a pointer to a function.  I figgured it would generate
> an error (since functions do not have a "size"), but being curious, I tried it
> on a few C compilers I had around.  Suprisingly, many don't flag it as an
> error at all and do something implementation-defined and unpredictable (for
> example, Lattice C 3.10 on the Amiga treats it as if it were a char *, which
> I find odd, because it generates 68000 code which must be even-address
> aligned - I would have at least expected it to treat it as a short *).
> 	K&R doesn't say anything about this (as far as I know).  I think it
> shows a breakdown in the typing system - pointers to functions aren't really
> pointers, but a distinct type.  Thoughts?  Flames?

This reminded me of a long-standing inconsistency in C in treating
labels.  The old pdp11 C compiler used to think labels were actually
constant-valued pointers to instructions, and you could in fact use
them that way.  According to K&R, this treatment was just plain wrong -
labels are a separate type - but I had a few systems programmers
telling me that the idea is useful AND THAT THEY HAD USED IT.

It seems to me that address arithmetic on pointers to functions ought
to be scaled to maintain alignment, as suggested above, and that this
might be part of a "clean" assembly/monitor interface.  However, as I've
pointed out, one could easily extend this concept to make labels be
treated as the type "pointer to in-line code."  I'm not sure I like
this idea, but, as noted above, I know at least a few C programmers
who'd be happy I mentioned it.  Actually, I guess I'm against the idea
because it would really destroy compile-time flow analysis...  but I
felt I should point out the issue anyway.

						-hankd