Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!beta!unm-la!unmvax!hi!hc!ames!ptsfa!hoptoad!academ!uhnix1!sugar!peter
From: peter@sugar.UUCP (Peter DaSilva)
Newsgroups: comp.lang.c
Subject: Re: (*pointer_to_function_returning_int)(args)
Message-ID: <242@sugar.UUCP>
Date: Tue, 30-Jun-87 19:52:56 EDT
Article-I.D.: sugar.242
Posted: Tue Jun 30 19:52:56 1987
Date-Received: Sat, 4-Jul-87 03:58:44 EDT
References: <16673@cca.CCA.COM> <7048@mimsy.UUCP> <786@geac.UUCP> <7219@mimsy.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 16

> Existing C compilers have only the types `char', `short', `int',
> `long', and unsigned variants, with one of `short' or `long' being
> synonymous with `int'; `float' and `double'; pointer-to; array;
> structure; member of structure; enum; member of enum; and function

Some existing 'C' compilers have "unsigned" as a variant of "int",
and no "unsigned char" or "unsigned long". Ritchie's, for example.
Some (Whitesmith on the 8080, for example) have "short" synonymous
with "char". Quite a few don't have enum. So the situation is even
more extreme than you already suggest.

I do think that "&f" should be acceptable, and "pf()" discouraged.
It makes it harder to follow code if people use "pf()", and "&f" is
more consistent with the rest of the language.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)