Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!camelback!volpe From: volpe@camelback.crd.ge.com (Christopher R Volpe) Newsgroups: comp.lang.c Subject: Re: is (int (*)())NULL legal when NULL is (void *)0? Message-ID: <13870@crdgw1.crd.ge.com> Date: 15 Nov 90 20:50:47 GMT References: <1391@gtx.com> <14457@smoke.brl.mil> <13799@crdgw1.crd.ge.com> <14463@smoke.brl.mil> Sender: news@crdgw1.crd.ge.com Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe) Lines: 36 In article <14463@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: |>In article <13799@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: |>-In article <14457@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: |>-|>In article <1391@gtx.com> randy@gtx.UUCP (Randy D. Miller) writes: [Deleted example] |>-|>No, the second is not required to be supported by the implementation, |>-|>but the first is (3.2.2.3). |>-What's wrong with the second example? A null pointer constant |>-represented by "(void *)0" is first cast to a function pointer (perfectly |>-legal), and the resulting expression is assigned to the variable |>-f2, of identical type, which should also be legal. Can you explain the |>-problem? |> |>The problem is that you can't point to any requirement in the standard |>that the implementation support casting (void*)0 to a pointer to function. It seems to me that the "spirit" of the cast operator is to make explicit a conversion where otherwise there would be no conversion or the conversion would be implicit rather than explicit. If the implicit conversion in example 1 is allowed, shouldn't the explicit conversion to the same thing be allowed? 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? I don't see it in 3.3.4? Doesn't this fall into the same category? Neither violates the constraint in 3.3.4, but then neither is explicitly supported. Both *conversions* are supported, if done via assignment operators. ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com