> Whether with -wrapv or with the unsigned macros, we simply disable some
> compiler optimizations, perhaps some good optimizations too.

Most certainly, yes.  But there are a lot more things that slow down the 
potential performance of FreeType -- C in itself is a trade-off between 
maintainability and performance.

> Why? Is it because we got scared? There is absolutely no evidence of real bugs
> in FreeType. It is reasonable to disable optimizations with  -wrapv, if
> scared, but macros are too rigid. Some compilers recognize /* fall through */
> comment to suppress particular warnings. I wish we could just add a comment to
> silence these warnings after adjudication.

It's not about being scared but about making sure we understand _what_ the code 
within FT does.  If we proactively mark operations that have a certain 
behaviour we make those operations explicit to whomever reads that thing in the 
future.  `-wrapv' has two downsides IMO:  (1) we lose track of what it does and 
_where_ ... maybe, really covering up bugs (2) we rely on 3rd parties to 
compile FT in a very specific way to avoid certain types of reports.

Freetype-devel mailing list

Reply via email to