Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

Subject:  Re: Pointers to functions

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7237
          for SXJVK at ALASKA; Sat, 12 Mar 88 01:24 AST
Received: by UWAVM (Mailer X1.25) id 4931; Sat, 12 Mar 88 02:19:22 PST
Date:         Thu, 10 Mar 88 12:53:33 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         "ELIN Forsch.z." <RCVIE at TUVIE>
Subject:      Re: Pointers to functions
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>

In article <7811 at tut.cis.ohio-state.edu- mills-cl at pike.cis.ohio-state.edu
(christopher mills) writes:
-/*   I think D should have Ada-style comments...  */
-
-    Hello there.  I was writing a compiler for a simple C-like language of
-my own design for a single-board 6809 computer of mine, and I got around to
-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?

Neither. A correction: K&R say (in my German edition) that only a pointer
to an arry element and an integer may be added or subtracted and that no
other (pointer) arithmetic is allowed. The dpANS says that "one operand shall
be a pointer to an object and the other shall have integral type". An object
is defined as "a region of data storage in the execution environment, the
contents of which can represent values". This is a more liberate definition
for pointer arithmetic than K&R have. In any case, pointer arithmetic on
pointers to functions is prohibited.

In article <7689 at pur-ee.UUCP- hankd at pur-ee.UUCP (Hank Dietz) writes:
-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.

The idea to have the same pointer arithmetic on labels as on pointers to
functions seems to be a good one (in my opinion). It could help system
programmers to solve some problems via tricky programming (I know, I know, ...
tricky programming should not be propagated, but some problems can be solved
*only* by tricky programming). Secondly this would allow additional entry
points into functions. It seems to me as if K&R had something like that in
mind when they reserved the keyword entry. Has anybody information why this
feature has never been implemented?

        Dietmar Weickert,
            ALCATEL-ELIN Research Center, Vienna, Austria.