C Semantics in K Framework

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

Chucky,

> on that sentence.  The example I should have given goes something like:

I have been trying to come up with something less contrived.  The more
obvious examples are also caught by other wording:

int g(int, int);
int h(double);

int i(p1, p2)
int p1;
int p2;
{
//...
}

void f(void)
{
int (*a[2])() = {g, h};
a[0](1); // Constraint by 6.5.2.2p2

int (*b[2])() = {i, j};
b[0](1);  // Undefined by 6.5.2.2p6
}

> 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