Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Undelivered mail Message-ID: <12291@brl-adm.ARPA> Date: 12 Mar 88 11:06:54 GMT Sender: news@brl-adm.ARPA Lines: 73 Subject: Re: Pointers to functions [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7237 for SXJVK@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@BRL.ARPA Sender: Info-C List From: "ELIN Forsch.z." Subject: Re: Pointers to functions Comments: To: info-c@brl-smoke.arpa To: Vic Kapella In article <7811@tut.cis.ohio-state.edu- mills-cl@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@pur-ee.UUCP- hankd@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.