Re: [ft-devel] longjmp issue 1

[suzuki toshiya]

Dear Werner,

I'm quite sorry for my latency with this issue.
I guess this error might be caused by a removal of
FT_INVALID_().

otvalid has a super validator class, OTV_Validator,
which includes FT_Validator as a member
(otvalidator->root is typed as FT_Validator).

To use FT_INVALID() samely in ttcmap/otvalid/gxvalid
(where the validators are differently typed,
FT_Validator/OTV_Validator/GXV_Validator),
FT_INVALID() is defined as a thin wrapper of FT_INVALID_(). 
FT_INVALID_() is dependent with the validators.
You can find that otvcommn.h undefines FT_INVALID_()
then redefines FT_INVALID_().

Thus, the easiest solution would be keeping both of
FT_INVALID_() and FT_INVALID() in ftvalid.h, and,
updating FT_INVALID_() in otvcommn.h to new syntax.

I attached a sample patch. I could reproduce SEGV
by Roboto-Thin.ttf, and the binary with the sample
patch does not crash.

--

However, current switching mechanism is not the best
solution for the maintainer - when somebody changes
FT_INVALID() syntax, 3 files must be synchronized
consistently (and it does not documented, I'm quite
sorry). In addition, some code assumes the type of
`valid' as FT_Validator, and other code assumes it
as OTV_Validator - this naming convention is confusing.

Considering that the super classes in otvalid/gxvalid
includes FT_Validator as a member, changing surrounding
codes in otvalid/gxvalid to call original FT_INVALID()
(defined in ftvalid.h) would be possible.

I will post alternative patch within 2 weeks.

Regards,
mpsuzuki

On the other hand,

On 2014/12/07 19:31, Werner LEMBERG wrote:
> Folks,
>
>
> I tried to apply the attached patch so that it is possible to set a
> breakpoint at `FT_Throw' while doing OTF validation[*], however, I
> always get segfaults with ftvalid, and I don't know why.
>
> Anyone who has an idea what's going on?  I'm using gcc 4.7.2 on a
> GNU/Linux box, in case this is of importance.  And please don't answer
> with `longjmp is evil'...
>
> I've also attached `Roboto-Thin.ttf', together with the output of
> valgrind (current SVN version) applied to a `ftvalid' binary created
> with `make devel; make' of current git.
>
>
>      Werner
>
>
> [*] Reason is that currently `ftvalid' simply says `Roboto-Thin.ttf
>      is invalid', without showing the error code.  In this particular
>      case it's an invalid glyph ID.
>
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

mps20141209a.diff.xz
Description: application/xz