C Semantics in K Framework

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

Chucky,

Sorry for delay in replying.

> Thanks for thinking about this.  There's a problem with your first
> example though.  Furthermore, I can't figure out how to fix it in a

Oops, a beginner's mistake on my part :-(

The problem with you suggestion:
pf = (int (**)(int))((char*)pf + offsetof(struct s, f2));

is that the pointer casts have rendered the whole thing
non-strictly conforming before we get to an actual call.

The following will work if the offset is an integral multiple
of the size of pf (likely to be true in many real life cases).

pf+=(offsetof(struct s, f2)/sizeof(pf));

> ...
> 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
> /*
> offsetof returns the offset in bytes.
> However, pf += number will actually move (number * sizeof) bytes.
> something like this instead:
> pf = (int (**)(double))((char*)pf + offsetof(struct s, f2));
> works in GCC, but all that pointer casting makes me uneasy.
> I guess you're guaranteed proper alignment, it still seems strange.
> */
>         (**pf)(2); // types not compatible (segmentation fault with gcc)
> }
>
> Any thoughts about the pointer conversions?  Is this example still okay?
>
> -Chucky
>
> On Wed, Feb 8, 2012 at 2:28 PM, Derek M 
> Jones<derek AT knosof.co.uk>
>   wrote:
> > 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
> > _______________________________________________
> > 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