Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
Undefined does not mean scary. Actually yes. Have you read e.g. http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html? Why do we even care? The burden is actually on the compiler to not do anything crazy or face consequences from users and public. For some reason the burden is put on the innocent and quite reasonable public. This does not make sense. I think if you are innocent and reasonable, you don't use C/C++ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
> 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. Undefined does not mean prohibited. Undefined does not mean scary. Undefined does not mean immoral. Why do we even care? The burden is actually on the compiler to not do anything crazy or face consequences from users and public. For some reason the burden is put on the innocent and quite reasonable public. This does not make sense. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
>> .. 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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
> > .. 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. > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
