> We can say something like: > > "In GNU C, you may cast a function pointer of one type to a function > pointer of another type. If you use a function pointer to call a > function, and the dynamic type of the function pointed to by the > function pointer is not the same as indicated by the static type of the > function pointer, then the results of the call are unspecified. In > general, if the types are not too different (e.g., the dynamic type is > "void ()(unsigned int)" while the static type is "void ()(int)"), then > the results of the call will probably be as you expect. However, if the > types are sufficiently different, there is no guarantee that your > program will behave in any predictable fashion." > > The use of "unspecified" here (as opposed to "undefined") indicates > that, while we're not saying what happens, we're also suggesting that > this is a more benign issue. > >
It may lead to misunderstanding since standard uses "unspecified behavior" wording with other meaning: when standard provides two or more possibilities and imposes no requirements on which is chosen, i.e. "the order of evaluation of function-call parameters is unspecified". The result of calling function pointer casted to sufficiently different type is a real example an undefined behavior. I suggest to avoid using "unspecified" wording here.
