>> .. 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

Reply via email to