Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ptsfa!hoptoad!academ!uhnix1!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter DaSilva)
Newsgroups: comp.lang.c
Subject: Re: Another portable code question
Message-ID: <225@sugar.UUCP>
Date: Thu, 25-Jun-87 21:24:56 EDT
Article-I.D.: sugar.225
Posted: Thu Jun 25 21:24:56 1987
Date-Received: Sat, 4-Jul-87 22:28:18 EDT
References: <16673@cca.CCA.COM> <1763@ttrdc.UUCP> <16769@cca.CCA.COM> <1019@killer.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 18
Summary: Unless something's changed since K and R...

> There it is in a nutshell, you really don't need the * unless the function
> is declared int (**func)();, then you have pointer to pointer to a function
> returning an integer.

According to K and R (1) You do need the *, and (2) (func)() should be
identical to func(). I'm not sure I approve of compilers taking it upon
themselves to turn func() into (*func)() without telling me, and I certainly
won't assume that it will work in any compiler I might come across. The
meaning of pointers to functions should be well defined. Lately the meanings
of all sorts of things has become problematical.

While I'm here, let me bitch about structure passing. I really don't think
there's any reason for passing anything larger than a double on the stack.
If you want to have a routine to copy it into local storage, you can always
allocate another copy on the stack in the routine and memcpy() it. It won't
be significantly slower. On the other hand I've been bitten more than once
by leaving out an ampersand and having 10,000 bytes pushed on an 8,000 byte
stack. UNIX => C but C !=> UNIX.