Re: [ft-devel] ft_setjmp in Codewarrior

[Antoine Leca]

address@hidden wrote:

Wow, you've done a great and detailled analysis.

> Thinking about a code like:
>
> struct a_struct_ {
> jmp_buf  jb_memb;
> } volatile* a_struct_ptr;
>
> volatile jmp_buf* dest = &( a_struct_ptr->jb_memb );
...
> For "volatile jmp_buf* dest", according to the error message
> by Metrowerks C compiler:
>
> Error : illegal implicit conversion from 'long *volatile  (*)[70]'
> to 'volatile long * (*)[70]'
>
> the memories pointed by the *dest elements are qualified as
> volatile. This would NOT be expected qualification, because
> the machine status is stored in the *dest elements, not in
> the memories pointed by the *dest elements.

Agreed, there is a bug in the determination of the type for the dest object:
assuming jmb_buf is declared as array of _JBLEN elements of type _JB_t, it
sees dest as
    volatile _JB_t [_JBLEN]
instead of the correct
    _JB_t volatile [_JBLEN]
When _JB_t is a simple type like int, there is no difference; but when there
is a pointer embedded within _JB_t, there IS a difference.

By the way, it may be useful to report this bug to Metrowerks. Judging from
the form they are using for the error message, where volatile comes /before/
the type specifier, it looks like they have a problem of priority inside the
type evaluation code...


> Therefore, an insertion of cast (volatile jmp_buf *) to right
> side for Metrowerks C compiler may not be good idea, because
> the interpretation of left side would be the root of problem.

Yes.


...
> So, now I have 3 workarounds:

Did you try

  jmp_buf volatile* dest = &( a_struct_ptr->jb_memb );

If this works, you've got a 4th workaround: there is no difference for a
conforming compiler between the two forms, but it might help a faulty
compiler to insert the volatile qualifier in the right place.

If this doesn't, I agree b is (much) better.

> c) Use "volatile void*" instead of "volatile jmp_buf*".

BTW, c is technically incorrect, since void* can have a different
representation from jmp_buf*; of course, this is not the case of mainstream
desktop compilers with 4GB address space, but it may be encountered e.g. in
segmented architecture like 16-bit i8086, where the jmp_buf* could be a
16-bit "segment" pointer, while void* would be a 32-bit "far" pointer.


Antoine