🚀 go-pugleaf

Sorry if this is a repost - my previous attempt apparently never made
it to the net  -- Bruce Blodgett

In article <1990Nov14.031125.14027@athena.mit.edu> tada@athena.mit.edu (Michael J Zehr) writes:
>In article <1990Nov13.174920.2235@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>>In article <1990Nov12.211511.2344@batcomputer.tn.cornell.edu> lijewski@theory.tn.cornell.edu (Mike Lijewski) writes:
>>>double f(double x) { return x * x; }
>>>   void *ptr = f;
>>
>>Function pointers are a whole different universe from normal pointers, in
>>principle.
...
>                        K&R2 (p. 199, "Any pointer may be converted to
>type void * without loss of information.

And in article <14450@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>Certainly.  It violates a constraint in section 3.3.16.1.

The relevant portion of the constraint from section 3.3.16.1 is:
one operand is a pointer to an object or incomplete type and the other
is a pointer to ... *void*

Section 3.2.2.1 states:
A *function designator* is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary &
operator, a function designator with type "function returning *type*"
is converted to an expression that has type "pointer to function
returning *type*."

Section 3.1.2.5 defines *object types* as:
types that describe objects

Section 1.6 defines *object* as:
a region of data storage ...
            ^^^^
Section 3.1.2.5 defines *incomplete types* as:
types that describe objects but lack information needed to determine
their sizes

Functions are neither objects nor incomplete types, and
pointers to functions are neither pointers to objects nor to
incomplete types.  Never-the-less, functions do have addresses.
Was it really the intent of the ANSI C committee not to allow void
pointers from holding uncasted function addresses (in either
conforming or strictly conforming programs)?
Bruce Blodgett
blodgett@apollo.hp.com
(508) 256-0176 x4037