Fred J. Tydeman wrote:
> On Sat, 29 Aug 2009 10:22:34 +0100, Geoff Clare wrote:
...
>>Personally, I can't find anything in C99 that requires the warning,
>>but just because I can't find it doesn't mean it's not there.
>
> I am using WG14 N1362 (C1x) as my reference document, as it is C99
> plus all the Technical Corrigendums plus some of the approved changes
> for the next version of C.
>
> A conversion of a pointer can be done via 6.5.4 (Cast operators) or
> 6.5.16.1 (Simple assignment). Neither of those two has an explicit
> constraint on pointer to void being converted to pointer to function.
There is an important difference: 6.5.16.1 has a long list of combinations of
types that are allowed in a simple assignment, and none of them mixes a
function pointer with a data pointer, whereas the constraints of 6.5.4 allow
casts from any scalar type to any other scalar type, including all possible
pointer types. This means that converting between a function pointer and a
data pointer by simple assignment violates the constraints of 6.5.16.1 and
therefore requires a diagnostic, while a similar conversion by an explicit cast
is not a constraint violation, and does not require a diagnostic, even when it
has undefined behaviour.
> 6.3.2.3 (Pointers) makes no mention of pointer to void being converted
> to pointer to function, therefore, that conversion is implicitly
> undefined behaviour (by 4. Conformance, paragraph 2).
Right.
> Aside: the
> constraints for these kinds of conversions are in 6.5.4 Cast
> operators.
Pedantically speaking, the constraints for the various kinds of syntactic
costructs that involve conversions (such as casts, assignments, or binary
operations on values that may require conversions to a common type) are
described separately for each of those constructs. The C standard does not
specify any general constraints that apply to all conversions.
> 5.1.1.3 (Diagnostics) only requires a diagnostic for a violation of
> syntax or constraints. There is no required diagnostic for implicit
> undefined behaviour.
|