Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: is (int (*)())NULL legal when NULL is (void *)0?
Message-ID: <14498@smoke.brl.mil>
Date: 17 Nov 90 13:29:20 GMT
References: <13870@crdgw1.crd.ge.com> <14484@smoke.brl.mil> <13920@crdgw1.crd.ge.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 65

In article <13920@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>In article <14484@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
>|>In article <13870@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com
>(Christopher R Volpe) writes:
>|>>If the above is not true, then where in the standard does it say that
>|>>an implementation must support casting an int into a float?
>|>Conversions involving pointers have an explicit set of requirements
>|>in 3.3.4 beyond the basic semantics.  The basic semantics suffice for
>|>interconversion of arithmetic values; 3.2.1.3 gives details.
>3.3.4 doesn't clearly define "basic semantics" and certainly doesn't
>say that it supports interconversion of arithmetic values.

The first paragraph of 3.3.4 Semantics is what I referred to as the basic
semantics.  The rest of that section are further conditions that apply
solely to conversions involving pointers.  It is clear what arithmetic
values are, but not clear what pointer values are, thus the need for
additional rules explaining what is required to be supported for pointers.

>3.3.4 doesn't say that it supports the conversions in 3.2.1.3.

For conversion by casts, 3.3.4 Semantics first paragraph covers it.
For conversions upon assignment or an operation specified to be as if
by simple assignment, 3.3.16.1 covers it.  3.3.16.1 Constraints limits
what is permitted for pointers (in a strictly conforming program), and
3.3.4 Semantics past the first paragraph spells out all other ways that
pointers may be converted (in a strictly conforming program).

If you think that these portions should not have been buried in the
sections where they are in fact found, many on X3J11 would tend to
agree with you.

>So, is K&R2 wrong here?

Yes, assignment and conversion by cast have slightly different semantics.
(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.)

>BTW, Doug, since you claim that "(int (*)())NULL" is illegal, I assume
>you mean that it is illegal whether NULL is defined as "0" or "(void *)0",
>right? Your argument about null pointer constants doesn't (I assume)
>depend on the form in which that constant is specified. So the above
>subject line is a little misleading. 

The subject line was inherited from the original posting.
Indeed, I don't think an implementation is required to accept
	(int (*)())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.)

>Ok, I would like to send X3 a request for an interpretation ruling.
>Can someone kindly tell me how to go about doing this?

Send a letter to X3 Secretariat: Computer and Business Equipment
Manufacturers Association, 311 First Street, N.W., Suite 500,
Washington DC 20001-2178.  Briefly state the issue, including
references to the relevant parts of the C standard, give a good
example, state the possible alternative interpretations, give an
argument for the interpretation you would prefer, and request
that the matter be brought before the X3J11 technical committee
for a decision on how to interpret the standard in such a context.

P.S.  Reminder: These opinions are mine, not necessarily X3J11's,
and X3J11 may decide upon a different interpretation.