--- Garrick Meeker <[EMAIL PROTECTED]> 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;
(see
http://cvs.savannah.gnu.org/viewcvs/freetype2/include/freetype/internal/ftvalid.h?cvsroot=freetype&r1=1.2&r2=1.3)
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
definition
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...
Jens
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
