C Semantics in K Framework

[Chucky Ellison <celliso2 AT illinois.edu>]

Sorry, I meant
pf = (int (**)(int))((char*)pf + offsetof(struct s, f2));

On Mon, Feb 13, 2012 at 11:07 AM, Chucky Ellison 
<celliso2 AT illinois.edu>
 wrote:
> 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