>> 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.
For reference, find the patch attached (most code in that area is already wrapped in `*_LONG' macros). @Werner: should I apply it? Armin
977845.patch
Description: Binary data
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
