Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

> The variable, gxvalid->statetable.entry_glyphoffset_fmt, it is set > by gxv module internally not imported from external font file (thus, > malicious input data cannot set the value to the undefined > value). So it is OK to remove the default case. Done. Werner

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

On 20 Jan 2016, at 14:26, John Emmas wrote: > On 20 Jan 2016, at 14:12, Werner LEMBERG wrote: > >> >> Try switching off the `precompiled header files' option. >> > > Thanks for the quick reply Werner. > > I'll check - but i'm 99% certain that I never use precompiled headers... :-( > Yeah -

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

> Yeah - precompiled headers are turned off for both pango and > freetype2. Hopefully some other MSVC user can confirm if they see > the same problem. Can you call the preprocessor only, then checking the expanded source code for the problem? Werner

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

Indeed. The following change essentially changed FreeType API in an incompatible way. I suggest reverting it. In general, I suggest not making too many cosmetic changes to a library so widely used. commit 37412ff9f42212bcf4dd29d9762f3c35b5735768 Author: Werner Lemberg Date:

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

Sorry for lated response about this issue. Yes, about this case, I agree with the removal of redundant default case after the complete list of possible enum values. The variable, gxvalid->statetable.entry_glyphoffset_fmt, it is set by gxv module internally not imported from external font file

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

> The following change essentially changed FreeType API in an > incompatible way. [...] Fixed in git. Thanks for both the report and the analysis. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] error: conflicting types for 'af_shaper_get_coverage'

> freetype/san_cov/src/autofit/afshaper.c:577:3: error: conflicting > types for 'af_shaper_get_coverage' [...] Fixed in git, thanks for the report! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

On Wed, 20 Jan 2016 13:36:06 +0100, Werner LEMBERG said: > >>> The `default' case is redundant, since all possible enum values are >>> covered in the `switch' statement. >> >> I personally prefer having code in front of me that I can prove >> correct, than having to go fish for all the places

[ft-devel] error: conflicting types for 'af_shaper_get_coverage'

Trying to build the fresh freetype from git with "./configure --with-harfbuzz=no" I get this failure: freetype/san_cov/src/autofit/afshaper.c:577:3: error: conflicting types for 'af_shaper_get_coverage' af_shaper_get_coverage( AF_FaceGlobals globals, ^

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

On 16-01-20 12:03 PM, Werner LEMBERG wrote: > >>> +#if 0 >>>default: >>> GXV_SET_ERR_IF_PARANOID( FT_INVALID_FORMAT ); >>> goto Exit; >>> +#endif >> >> What's this?! > > The `default' case is redundant, since all possible enum values are > covered in the `switch'

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

On 16-01-19 07:16 PM, Werner LEMBERG wrote: > +#if 0 >default: > GXV_SET_ERR_IF_PARANOID( FT_INVALID_FORMAT ); > goto Exit; > +#endif What's this?! ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] ABI in detail

19.01.2016, 20:32, "Werner LEMBERG" : >>  I'm working on a new project for high-detailed binary compatibility >>  analysis of C libraries (alternative for the abi-compliance-checker >>  project) and I've got interesting results for FreeType 2.6.2. > > Thanks, but what exactly are the

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

>> +#if 0 >>default: >> GXV_SET_ERR_IF_PARANOID( FT_INVALID_FORMAT ); >> goto Exit; >> +#endif > > What's this?! The `default' case is redundant, since all possible enum values are covered in the `switch' statement. Toshiya-san, shall I completely remove this code?

Re: [ft-devel] ABI in detail

> The report can be used as the reference for the FreeType API at > binary level. You can view how parameters are passed to API > functions (calling conventions) and memory layouts of data types in > the report. Looking at

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

>> The `default' case is redundant, since all possible enum values are >> covered in the `switch' statement. > > I personally prefer having code in front of me that I can prove > correct, than having to go fish for all the places that value in the > switch statement is set to convince myself

Re: [ft-devel] ABI in detail

>>> I'm working on a new project for high-detailed binary >>> compatibility analysis of C libraries (alternative for the >>> abi-compliance-checker project) and I've got interesting results >>> for FreeType 2.6.2. >> >> Thanks, but what exactly are the `interesting results'? Please >> elaborate.

[ft-devel] Pango error due to #including FT_ERRORS_H

I posted this to the pango mailing list a few minutes ago but it just occurred to me that this list might be better... I updated freetype2 a few days ago (i.e. I pulled the latest source code from git) and I've just realised that pango fails to build now (with MSVC). The problem is at these

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

On 20 Jan 2016, at 14:12, Werner LEMBERG wrote: > >> My best guess is that something got changed somewhere in >> 'freetype/fterrors.h'. It does look like something got done (about >> a week ago) to remove underscores from some macro names but I'm not >> sure why that would cause this problem.

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

> My best guess is that something got changed somewhere in > 'freetype/fterrors.h'. It does look like something got done (about > a week ago) to remove underscores from some macro names but I'm not > sure why that would cause this problem. Can anyone hazard a guess > at what might be wrong?