C Semantics in K Framework

[Chucky Ellison <celliso2 AT illinois.edu>]

Derek,

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
non-awkward way.

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