Re: [ft-devel] ft_setjmp in Codewarrior

[mpsuzuki]

Dear Antoine,

On Wed, 12 Nov 2008 10:11:42 +0100
"Antoine Leca" <address@hidden> wrote:
>> 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.

Many thanks for your proposal of 4th workaround. I've tried
that, but I got exactly same error.

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

Also thank you pointing out this. Yes, in fact, classic MacOS
environment have near & far pointer :( I must drop workaround C.

Originally, I thought this issue is very special case,
a combination of no-longer-sold platform (classic MacOS)
and no-longer-sold SDK (CW for MacOS). Thus, Werner proposed
to collect the problematic parts and separate them to new
source file, and override it by builds/mac/ftXXX.c.
But when I checked the testing code by the latest CW for
embedded platform, I found that same issue arises.

In CW for ColdFire (a 32bit micro controller derived from
m68k architechture), jmp_buf is defined as an array of long
pointer, aslike CW for classic MacOS and MPW. And, my testing
code cannot be compiled normally because of implicit cast.
ColdFire SDK is completely independent with MacOS, but
CW for ColdFire can understand the pragma "mpwc_relax"
designed for CW for MacOS, and it makes CW for ColdFire
ignore the implicit cast issue.

In CW for MPC55xx (PPC-based embedded platform), jmp_buf
is defined as an array of long integer. So the problem
does not arise. Anyway, if check the interpretation of
"volatile array_of_long_pointers_t*", it is interpreted as
"long volatile *(*)[n]" (we expect "long* volatile (*)[n]").

So, the implicit cast issue is not exceptional error in
CW for MacOS/ColdFire. Thus, I want to insert CW-specific
pragma as following.
--------------------------------------------------------------
  FT_BASE_DEF( void )
  ft_validator_error( FT_Validator  valid,
                      FT_Error      error )
  {
    /* since the cast below also disables the compiler's */
    /* type check, we introduce a dummy variable, which  */
    /* will be optimized away                            */
#if defined( __MWERKS__ ) && ( __MWERKS__ > 0x1100 )
    /* Recent CodeWarrior C compilers exchange a qualifier  */
    /* and a dereference to gather all dereferencers to the */ 
    /* right end. We make CW C compilers ignore an implicit */
    /* type casting of the pointer. Old CW had no problem.  */
#pragma mpwc_relax on
#endif
    volatile ft_jmp_buf* jump_buffer = &valid->jump_buffer;
#if defined( __MWERKS__ )
#pragma mpwc_relax reset
#endif


    valid->error = error;

    /* throw away volatileness; use `jump_buffer' or the  */
    /* compiler may warn about an unused local variable   */
    ft_longjmp( *(ft_jmp_buf*) jump_buffer, 1 );
  }
--------------------------------------------------------------

Please give me comment!

Regards,
mpsuzuki