is (int (*)())NULL legal when NULL is (void *)0?

[Chris Torek]

In article <14498 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>Yes, assignment and conversion by cast have slightly different semantics.

Aside from casts being permitted where assignments are not, I think this
is a Bad Thing.  Having a cast `mean' the same thing as an assignment,
with the addition that (being explicit) it is a little more `powerful'
and can override objections like `the pointers have different types',
significantly reduces what I might call the `cognitive size' of the
language.  It is much easier to think of

	i = (short)j;

as `get the value of j, put it in a short, and pull it back out' than
as `apply a short cast, with separate semantics from assignment to a
short, to get a result'.  The latter requires one to carry the separate
semantics around in one's head in order to be able to decide what the
code above means.  (Obviously one must always carry assignment semantics
around, unless one never uses assignment.  This, however, doubles the
load.)

>(I won't attempt to guess whether or not this was intentional, but it
>should be presumed to be so unless X3J11 later declares otherwise.)

I hope they do so declare.

>Indeed, I don't think an implementation is required to accept
>	(int (*)())0
[or	(int (*)(void))0	?]
>but it also is not required to diagnose it (because it is not a syntactic
>or constraint violation), and thus it may elect to support it.  (Many old
>implementations did.  They need not stop doing so, but portable coders
>should become aware of this and avoid using such constructs.)

This would make it difficult to pass a `nil pointer to function of no
arguments returning int' to a function for which no prototype can be
provided.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris