Re: [ft-devel] Problems building Freetype 2.10.0 on VS2005
On 31/05/2019 19:19, Alexei Podtelezhnikov wrote: I think I found a solution. Can you try this instead of your patch? #include #pragma intrinsic(_BitScanReverse) Apologies for the slow reply - I was travelling all last week. I've just tested this, and it seems to work fine. Thanks! Robin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems building Freetype 2.10.0 on VS2005
On 31/05/2019 18:07, Alexei Podtelezhnikov wrote: On Fri, May 31, 2019 at 12:13 PM Robin Watts wrote: Despite intrin.h defining this function, it's not there on linking. Release builds work fine. I fear VS2005 is broken in this regard. Could the problem be that the Debug mode does not define /Oi by default, i.e. all VS versions would fail in debug mode with your custom project files? We actually have EnableIntrinsicFunctions="true" in both Debug and Release configurations in the out-of-box project files. Can you try adding that option to your Debug configuration? You are correct in that we have EnableIntrinsicFunctions set to no for Debug builds. Sorry, I should have spotted that. So maybe this doesn't only affect VS2005 builds, but ALL VS builds. It seems likely we *could* solve the problem by setting that to be true, but (due to the way our build is structured) that would enable intrinsics for far more than just freetype. The only thing that gives me pause about doing this, is that presumably there must be a reason why it's not set like that out of the box (i.e. in a standard newly generated VS project file for Debug mode). Does it harm the debuggability of the generated exe? It seems to me "suboptimal" for freetype to require this non-standard setting. Maybe freetype should only call the intrinsic in Release builds? Just thinking out loud here; we'll try and go with whatever you think best. Thanks, Robin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Problems building Freetype 2.10.0 on VS2005
Gents, We have recently updated MuPDF to use Freetype 2.10.0, and we've hit a problem with it. On machines with fully updated VS2005 Pro installations, we find that builds in Debug mode fail, due to ftcalc.h defining FT_MSB_i386 to call _BitScanReverse. Despite intrin.h defining this function, it's not there on linking. Release builds work fine. I fear VS2005 is broken in this regard. This has come to light because commit 2f218a4c3abf7: * include/freetype/internal/ftcalc.h (FT_MSB): Verified `_MSC_VER'. Actually `_BitScanReverse' is available since VS2005. has changed the source to rely on that function. Therefore, we are considering the following patch for Freetype in MuPDF: http://git.ghostscript.com/?p=thirdparty-freetype2.git;a=commitdiff;h=9dd1f98bc77307d26d48bdd1311e023bc8de65c7;hp=fbbcf50367403a6316a013b51690071198962920 Is that something you guys could take on upstream? Thanks, Robin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] C99, long long, and inline
On 12/09/2016 14:35, Alexei Podtelezhnikov wrote: Anyway, I am for the jump to C99 in 2.8. I would argue against it. Freetype is used in many many more places that you can imagine; lots of them will have strange historical compilers. Straining them is a bad idea. Personally I'd like to see freetype stay as C89, but to use some of the following features: *long long* Freetype emulates its own 64-bit arithmetic on LLP64 platforms (like Windows) in order to stay ANSI. This is crazy in this day and age. We should go C99 by default and and provide 64-bit emulation only if a user begs for it in ftconfig.h. The 'correct' thing to do (IMAO) is to use an int64_t (or ft_int64_t if you prefer) type. On systems that provide int64_t, we have no problems. On systems that don't provide it, then we can #define int64_t long long (or whatever is appropriate). And finally, and as a last resort, we can drop back to an emulation if there is no native 64bit type available. *inline* Freetype smooth rasterizer is very nested. I seems to me that gcc selects some inlining scheme. Does anyone know how to check this? I would like to have some control over inlining, which can be useful for performance tuning. Again, I'd argue for us just using 'inline' (or INLINE or FT_INLINE), and we can #define that as required. Relying on compilers to get optimisation right automagically is a mugs game. They can barely get compilation right... *other C99 features* Please voice your opinion. Please, please, please can we avoid the practise of introducing variables other than at the start of a block? When you suddenly have to get code that's been written in 'declare just in time' style working on compilers that don't support it, it's a massive pain in the behind. Just my 2c. Robin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MSVC build woes !
On 11/06/2013 13:08, John Emmas wrote:
#define FT_ASSERT( condition ) \
do\
{ \
if ( !( condition ) ) \
FT_Panic( assertion failed on line %d of file %s\n, \
__LINE__, __FILE__ ); \
} while ( 0 )
It usually gets called something like this:-
FT_ASSERT( some_var == some_other_var );
and wherever it gets called, I get warning 4127.
Indeed.
MSVC is warning that there's no point putting this in a do/while loop,
since nothing ever changes. Rather than re-instate the pragma, a
better solution would be to remove 'do' and 'while'.
No, no, no! Absolutely wrong!
There is a VERY good reason for the while being there. I will try to
explain:
Imagine that you have the following code:
if (x == 0)
FT_ASSERT(some_condition);
else
return 42;
return 23;
Without the while loop, the code would expand to:
if (x == 0)
if (!some_condition)
FT_Panic( ... );
else
return 42;
return 23;
(indentation changed for clarity)
i.e. the behaviour of the code is changed for x == 0; in the first case,
the assert would be tested, then 23 would be returned. In the second the
assert would be tested, then 42 would be returned.
By putting the do/while loop in, you avoid the possibility of the macro
changing the surrounding control flow.
When writing macros in C it is considered good style to try to minimise
unintended consequences of the macros use (a good example of The
Principle of Least Surprise).
At first glance, it doesn't look like
there'd be any adverse effects. If you agree that removing 'do' and
'while' is the way forward, I'll find you the other occurrences. Regards,
Those examples of do and while are put there very deliberately. Removing
them would be a harmful step.
It is true that the MSVC warning is unhelpful, so finding a way to stop
it (such as by putting the original set of lines back in) would be
preferable.
Robin
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
