>> .. and undo those macros? > > Well, if you then can? Signed integer overflow being undefined strikes me as a > severe deficiency in the C language. This of course makes -wrapv a compiler > level workaround, which may not be available to every compiler FreeType wants > to support. Hm.
It's one of many oddities of C ... Problem is that it's undefined behaviour and compilers are technically free to do anything with the calculation, including optimising statements away completely that have to be preserved when assuming wrap-around that could, maybe, end up becoming an actual bug with buffer overflow or whatever. Haven't constructed such an example yet though. Also, I agree with both of you: I think the current solution (casting everything for the sole purpose of silencing UB fuzzers) is an ugly way or introducing technically irrelevant overhead to the code base. On the other hand; the C standard is what the C standard is (maybe for good reason, maybe due to lobbying) but at least it is a standard that is being obeyed. As such, I don't think it's a good idea to suggest people should build FreeType in ways that change the C standard on a compiler level. This, sadly, brings us back to the current way of dealing with these things; adding ugly macros that transfer these operations from UB space into defined C space ... Not saying I'm happy with that but I believe this is the cleanest solution in the big picture right now. _______________________________________________ Freetype-devel mailing list Freetypefirstname.lastname@example.org https://lists.nongnu.org/mailman/listinfo/freetype-devel