https://issues.apache.org/ooo/show_bug.cgi?id=124073
[email protected] <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] |g | Target Milestone|--- |4.1.0 --- Comment #19 from [email protected] <[email protected]> --- Having debugged into this on Linux/Windows/Mac64 the difference in the problematic code I pointed out above (graphicprimitivehelper2d.cxx:762) is that some compilers - allocate the new MaskPrimitive, then construct it, then assign the pointer while other compilers (such as on Xcode's clang) - allocate the new MaskPrimitive, assign its pointer, then construct it Its a similar situation with the ordering of subexpressions such as i = 2 * (i++); where you CANNOT rely on the increment being done before the assignment (C++ standard 5.0.4) or with argument evaluation order (C++ standard 5.2.2.8), i.e. for a call fn1( fn2(), fn3()); you CANNOT rely on fn2 being called before fn3. If a construct has an undefined order according to the standard, but a result depends on a specific order, then this construct must be sanitized. Automatically detecting such problems introduced by such undefined-order constructs is AFAIK not yet possible, especially like the situation here where multiple different modules are involved. E.g. coverity didn't catch it. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. You are watching all bug changes.
