[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] ft_setjmp in Codewarrior

From: Jens Claudius
Subject: Re: [ft-devel] ft_setjmp in Codewarrior
Date: Sun, 24 Sep 2006 03:25:04 -0700 (PDT)

--- Garrick Meeker <address@hidden> wrote:

> In Codewarrior jmp_buf is declared as:
> typedef long *jmp_buf[70];
> so the volatile FT_ValidatorRec makes the pointers volatile but this  
> code in ftobjs.c fails:
> volatile jmp_buf* jump_buffer = &valid->jump_buffer;
> Error   : illegal implicit conversion from 'long *volatile  (*)[70]' to
> 'volatile long * (*)[70]'
> ftobjs.c line 95       volatile jmp_buf* jump_buffer = &valid->jump_buffer;

Back in August I changed the definition of FT_Validator to be

        typedef struct FT_ValidatorRec_ volatile*  FT_Validator;

because typically an FT_ValidatorRec object is allocated on the stack and
some fields of it are used after a call to (ft_)setjmp. For maximum safety
(and portablility) that may mean that it should be volatile.

This definition also made FT_ValidatorRec's field jump_buffer volatile so that
a volatile jmp_buf* is passed to (ft_)setjmp and (ft_)longjmp. Unfortunately
my compiler (GCC 4.1.1) does not emit a warning (not even with -Wcast-qual),
so this problem eluded me. (Strangely G++ 4.1.1 aborts with an error.)

> Before I submit a patch that explicitly casts:
> <             if ( ft_setjmp( FT_VALIDATOR( &valid )->jump_buffer )  
> == 0 )
> ---
>  >             if ( ft_setjmp( *(ft_jmp_buf*) &FT_VALIDATOR( &valid )- 
>  >jump_buffer ) == 0 )
> is there a better way to deal with this?

If a cast is unavoidable, it should perhaps go into ft_setjmp itself. But maybe
we can either do away with the volatile (but is this safe?) or change the
of FT_ValidatorRec like this:

    typedef struct  FT_ValidatorRec_
        const FT_Byte* volatile     base;
        const FT_Byte* volatile     limit;
        FT_ValidationLevel volatile level;
        FT_Error volatile           error;

        ft_jmp_buf          jump_buffer;
    } FT_ValidatorRec;

But I fear this will open just another can of worms...


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]