Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!coherent!aimt!breck
From: breck@aimt.UUCP (Robert Breckinridge Beatie)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Arrays of functions in THINK C
Keywords: Why does this not work?
Message-ID: <1131@aimt.UUCP>
Date: 3 Aug 88 14:51:34 GMT
References: <2884@mit-amt.MEDIA.MIT.EDU> <9651@dartvax.Dartmouth.EDU>
Organization: AIM Technology, Palo Alto, CA
Lines: 48

In article <9651@dartvax.Dartmouth.EDU>, earleh@eleazar.dartmouth.edu (Earle R. Horton) writes:
> In article <2884@mit-amt.MEDIA.MIT.EDU> phil@mit-amt.MEDIA.MIT.EDU (Phil Sohn) writes:
> >typedef int (*GEN)();
> >
> >int gen01();
> >
> >GEN gensub[10]= {NULL, gen01}
> >
> >gensub[1]();  <-  compiler produces an error here
> >
> 
> Try
> 
> (* gensub[1])();
> 
> ... K&R doesn't say anything about it.  Anybody
> care to eleaborate about what ANSI says?


Actually, K&R does say something about it.  On page 182  (section 7.1
of appendix A)  it says:

	A function call is a primary expression followed by parentheses
	containing a possibly empty, comma-separated list of expressions
	which constitute the actual arguments to the function.  The
	primary expression must be of type "function returning ...", and
	the result of the function call is of type "...".

At least I take this to mean that the primary expression shouldn't be
of type "pointer to function returning ...".  Funny, it's the unix
compilers that are broken in this case.  Of course my "analysis" may
be flawed.

Anyway, ANSI (October 1986 draft) proposal says in section 3.3.2.2:

	The expression that denotes the function called shall have type
	"pointer to function"*

	* Most often, this is the result of converting an identifier
	  that is a function designator.

So, the unix compilers conform to ANSI, but not K&R and LSC conforms to
K&R, but not ANSI.  Or so I think.

-- 
Breck Beatie	    				(415)856-8649
{uunet,ames!coherent}!aimt!breck
"Sloppy as hell Little Father.  You've embarassed me no end."