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

[Christopher R Volpe]

Sorry for wasting the bandwidth and your time, but...

In article <14484 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
|>In article <13870 at crdgw1.crd.ge.com> volpe at 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. 3.2.1.3
describes what happens WHEN this type of conversion takes place, but 3.3.4
doesn't say that it supports the conversions in 3.2.1.3. If this is
to be inferred from the phrase "the type name shall specify ... scalar type",
in 3.3.4 Constraints, then the pointer conversion in question falls
under the same category. 

The int->float conversion is no more explicitly sanctioned in 3.3.4 than
the pointer conversion. The use of the word "converts" in 3.3.4 Semantics
"""""implies""""" (note quotes) that conversions that are legal
"in general" are legal in a cast. Finally, K&R2 (yes, I know it ain't
gospel) says in 2.7:
      The precise meaning of the cast is AS IF [emphasis mine] the
      expression were assigned to a variable of the specified type...
So, is K&R2 wrong here? K&R1 says the same thing, and if this is
legal and well defined in K&R1, and not legal and well defined in
the Standard, and no diagnostic is required (since no constraint is
violated) then this qualifies as a QUIET CHANGE, which the rationale
fails to mention.

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. 

|>
|>>Both *conversions* are supported, if done via assignment operators.
|>
|>I can't parse that.

Ok, I guess I wasn't clear. I simply meant that each type of conversion
(int->float, null_pointer_constant->any_pointer_type) is
sanctioned in 3.3.16.1. No cast is REQUIRED for either. So an
implemention must be able to perform this kind of conversion, even if
the Standard doesn't explicitly say that this kind of conversion
can be done via a cast operator.

|>
|>Certain license beyond 3.3.4 is granted in 3.3.16.1 for assignment
|>involving certain pointers that meet the constraints of 3.3.16.1.
|>
|>If you have further questions about this, I suggest you send X3 a request
|>for an interpretation ruling.  Possibilities for misunderstanding are
|>limitless, and I really cannot spend much more time on this than I
|>already have.  I think the standard is clear on this.

Ok, I would like to send X3 a request for an interpretation ruling.
Can someone kindly tell me how to go about doing this?  At the very
least, even if X3 doesn't agree with me about the legality issue, I
think it would be interested to know about the discrepancy with
the rationale, which states that "the only integer that can safely
be converted to a pointer is the constant 0 [3.2.2.3 rat.]" and
that "The conversion of the integer constant 0 to a pointer is
defined similarly to the Base Document [3.3.4 rat.(cast operator)]".    
==================
Chris Volpe
G.E. Corporate R&D
volpecr at crd.ge.com