Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: (*pointer_to_function_returning_int)(args)
Message-ID: <7219@mimsy.UUCP>
Date: Fri, 26-Jun-87 17:10:26 EDT
Article-I.D.: mimsy.7219
Posted: Fri Jun 26 17:10:26 1987
Date-Received: Sat, 27-Jun-87 11:45:11 EDT
References: <16673@cca.CCA.COM> <7048@mimsy.UUCP> <786@geac.UUCP> <607@haddock.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 84

In article <607@haddock.UUCP> karl@haddock.UUCP (Karl Heuer) writes:
>Declarations: void f(void); void (*pf)(void);

>In article <7088@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>I daresay this change ... considering that it is no change at all to
>>some extant C compilers, is safe.

>I'm not sure what "safe" is supposed to mean here.

`Will not break any existing code.'

>I think the idea is that it's unlikely that anyone will ever want
>to use functions (as opposed to function pointers) as full-fledged
>objects.

They are not now (and I believe C as a language is not well
constructed to allow such things).  But that is not what I meant.

>My complaint is that, for any object x, it's logically inconsistent to have
>"x" automatically mean "&x".  Even if there's no way that "x" alone could have
>any meaning in the given context, having the compiler "know" that "&x" was
>meant -- and performing the substitution with no warning -- is a botch (in my
>opinion!).  (Worse yet, "pf = f" has always been the preferred form, and the
>logically correct "pf = &f" elicits a warning!)

>As I've said before, I would rather have the standard allow only the forms
>"f()" and "(*pf)()", and explicitly bless the syntax "pf = &f".  The "pf = f"
>notation (and hence the construct "(*f)()") is too deeply entrenched in
>existing code to be removed in this standard, but could be deprecated.  This
>would not be a big change (compared to the addition of function prototypes,
>say), and the common (but not universal) practice of allowing "pf()" could be
>a Common Extension, so nobody gets burned.

This argument is heading off in a different direction, and as long
as I am typing, I might as well add my own views.  I agree about
the logical inconsistency, and I would like to see a C-like language
in which everything save perhaps functions were first-class objects.
This requires adding aggregate constants and changing the behaviour
of arrays and functions, and probably adding strong typing a la
Mesa or C++.  Nonetheless, while I would like to see such a language,
I do *not* want this as a standard for C.  Such a language is not
C, and should not be claiming to be C.  I am deeply distrustful of
this new standard, even though there are remarkably few inventions
and new features, almost all being necessitated by differences
between existing compilers.  The single addition of function
prototypes is, in my opinion, a very substantial change, requiring
a great deal of thouht about the type system.

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
to deal with.  Unions are a special case of structure, and while
there may be a small number of different internal `pointer-to' and
`structure' types, there are still not that many types: 15, or a
few more.  Yet these compilers already have trouble with type
conversions: unsigned to double was broken in 32V and 3 and 4BSD
Vax PCC for years.  Now there are classes of functions, and function
types must be checked much more carefully.  Like pointers, each
kind of function is, at least theoretically, different, and the
type system must track each the way it now tracks pointers and
warns about misuses such as `int (*b)[6], **d; b = d;' (which---
incorrectly---passes the 4BSD compilers without a peep).

It is not that I think these changes are bad, or that I want to
keep the language from evolving (although that *is* the effect of
a standard), but making these changes standard without first testing
them bothers me.  At least the type system has been tried in C++,
where it seems to work quite well; but C++ is not C, and there is
no guarantee that its usefulness will transfer to C.  Microsoft
and GNU compilers already allow function prototypes, but both of
them (or at least the compilers I have tested) have bugs in this
area.  I think that these can be fixed, and so I am less worried
than I might be.

Ultimately, what really bothers me is that the standard does *not*
match C as it exists today (an impossible task, for C does not
match C---e.g., Microsoft 4.0 C vs. 4BSD PCC C).  How can we call
it a C standard?  At the very least, let us not ask it to change
things upon which all C compilers agree---or let us call it C2, or
P, or by some other name.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris