Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!tektronix!teklds!copper!stevesu
From: stevesu@copper.UUCP
Newsgroups: comp.lang.c
Subject: Re: How big is a (??? *)
Message-ID: <1121@copper.TEK.COM>
Date: Sat, 13-Jun-87 17:12:30 EDT
Article-I.D.: copper.1121
Posted: Sat Jun 13 17:12:30 1987
Date-Received: Sun, 14-Jun-87 18:36:59 EDT
References: <737@edge.UUCP> <790@mcgill-vision.UUCP> <1243@epimass.EPI.COM> <353@formtek.UUCP>
Organization: Tektronix Inc., Beaverton, Or.
Lines: 29

In article <353@formtek.UUCP>, kls@formtek.UUCP (Karl Swartz) writes:
> > Ah, but what about pointers to functions?  There are models for the
> > 80x86 architecture where pointers to data are 16 bits and pointers
> > to functions are 32  bits.
> 
> dpANSI explicitly avoids talking about casts between pointers to
> functions and pointers to (not-a-function).  The Rationale does
> say something on this, in section 3.2.2.3:
> 
>     "Nothing is said about pointers to functions, which may be
>     incommensurate with object pointers and/or integers."

Why not?  I understand that a (char *) might not be big enough,
but couldn't a (void *) be made large enough to hold the segment
numbers and other assorted rot for those funky memory models?
Or would that make (void *)'s unacceptably big and arithmetic on
them unacceptably slow?

I'm curious because the most stratospherically enlightened
programming paradigms tend to foster a blurring or removal of the
traditional text/data distinction.  I've written a few programs
(not many, I'll admit, and pretty esoteric ones at that) that
intermixed pointers to functions and pointers to data (through a
char *) with good effect.  (If you can't imagine a program that
would want to treat functions as data, you've never tried writing
a C interpreter.)

                                           Steve Summit
                                           stevesu@copper.tek.com