Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!apple!oliveb!felix!info-ultrix
From: pinkas@hobbit.UUCP (Israel Pinkas ~)
Newsgroups: comp.unix.ultrix
Subject: Re: ULTRIX-32 VAX C compiler bug
Message-ID: <88356@felix.UUCP>
Date: 21 Mar 89 20:52:37 GMT
References: <85725@felix.UUCP>
Sender: info-ultrix@felix.UUCP
Reply-To: pinkas@hobbit.UUCP (Israel Pinkas ~)
Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA
Lines: 51
Approved: zemon@felix.UUCP
Reply-Path:

Reply-to: pinkas@hobbit.UUCP (Israel Pinkas ~)


In article <85725@felix.UUCP> kjones@talos.UUCP (Kyle Jones) writes:

> Anyone know why vcc(1) gripes about pointers to functions being used
> as functions.  Example:
>
> main()
> {
>     int atoi();
>     int (*ascii_to_integer)() = atoi;
>
>     ascii_to_integer("3");
> }
>
> Compiling this program gives
>
> "bug.c", line 6: %E-NOTFUNCTION, Function-valued expression not found.
>
> "bug.c", line 7: %I-NOBJECT, No object file produced.
>
> "bug.c", line 7: %I-SUMMARY, Completed with 1 error(s), 0 warning(s), and
>		   1 informational messages.
>
> As far as I know K&R (1st edition) and the pANS allow this.  I know
> I've been using it for years without problems.  What's going on here?

Because it is wrong.  See K&R, 1st edition, pg 114-117.

They present a sort routine for strings which takes a comparison and
exchange function.  They state that with the declaration int (*comp)(),
comp is a pointer to a function returning int.  *comp is the function, and
(*comp)(<args>) is the proper call.

What they doi state is that when passing comp to the sort function, the
name of the function is sufficient (i.e. the & is optional).  They reason
for this is that the compiler can determine that the identifier is a
function, and functions are always passed by address (like arrays).  I
don't have a copy of the dpAns draft to check what they say about this.

-Israel Pinkas
--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.

UUCP:	{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas
ARPA:	pinkas%cadev4.intel.com@relay.cs.net
CSNET:	pinkas@cadev4.intel.com