This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 4.2 more strict check for "function called through a non-compatible type"


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]