C Semantics in K Framework

[Derek M Jones <derek AT knosof.co.uk>]

Chucky,

> In the semantics of function calls section, the standard (n1570)
> 6.5.2.2:9 says, "If the function is defined with a type that is not
> compatible with the type (of the expression) pointed to by the
> expression that denotes the called function, the behavior is
> undefined."
>
> I'm having some difficulty understanding this passage.  I'm finding it
> quite hard to parse (e.g., how can an expression point to a type or
> expression?),

"or" -> "of" ???

> but it seems to say that if I try to call a function,
> the type of the calling expression needs to be compatible with the
> type of the actual function.

Yes.  Thanks for pointing out the lack of insight in my commentary
on that sentence.  The example I should have given goes something like:

int g(double v)
{
printf("%fn", v);
}

struct s {
         int (*f1)(int);
         int (*f2)(double);
         } x;

int (**pf)(int);

int main(void)
{
x.f2=g;
pf=&x.f1;
pf+=offsetof(struct s, f2); // pf points to base of x so this is portable
(**pf)(2); // types not compatible (segmentation fault with gcc)
}

Using a union would not change the redundancy status because of
the wording that covers writing to one member and reading from
another.

> http://c0x.coding-guidelines.com/6.5.2.2.pdf suggests that "For this
> situation to occur either a pointer-to function type has to be
> explicitly cast to an incompatible pointer to function type, or the
> declaration visible at the point of call is not compatible with the
> function definition it
> refers to.
>
> If there is a casting, I don't understand how this is any different
> than 6.3.2.3:8, which says, "If a converted pointer is used to call a
> function whose type is not compatible with the referenced type, the
> behavior is undefined."  If the visible declaration is not compatible
> with the function definition, I don't understand why 6.2.7:2 wouldn't
> apply, "All declarations that refer to the same object or function
> shall have compatible type; otherwise, the behavior is undefined."
>
> Does anyone have any idea how 6.5.2.2:9 is any different than the
> above cases?  Ideally, via a program that is undefined only because of
> 6.5.2.2:9 and not 6.3.2.3:8 or 6.2.7:2.  Otherwise, 6.5.2.2:9 is
> redundant (and imho, poorly worded).
>
> -Chucky
> _______________________________________________
> c-semantics mailing list
> c-semantics AT cs.illinois.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/c-semantics

--
Derek M. Jones                  tel: +44 (0) 1252 520 667
Knowledge Software Ltd          blog:shape-of-code.coding-guidelines.com
Source code analysis            http://www.knosof.co.uk