Angus Johnson

> What am I missing? https://github.com/graphics32/graphics32/blob/8dfb597327c34706433df8150590f0a54752eabe/Source/Clipper.Offset.pas#L710-L722

Anders, I'm entirely happy for you to remove just about all attribution to me (eg just one line attribution) and use the existing Graphics32 copyright too. Edit: Further suggestions ......

I can't duplicate this problem. ``` Paths64 subject; subject.push_back(MakePath({ 0, -453054451,0, -433253797,-455550000, 0 })); subject.push_back(MakePath({ 0, -433253797,0, 0,-455550000, 0 })); Clipper64 clipper; clipper.PreserveCollinear(false); clipper.AddSubject(subject); Paths64 solution; clipper.Execute(ClipType::Union, FillRule::NonZero, solution); std::cout

Thanks for all the suggestions. However, please note that 1. the clipping engine doesn't use any trigonometric or logarithmic functions 2. the library _should_ be robust even when different compilers...

> 1. In my failing example, the coordinate values were well within the mentioned range: [-450M, 0] in my case. It would significantly reduce performance if Clipper were to test...

Perhaps one way around this issue might be using the following untested code. Instead of directly calling `CrossProduct()` to test for collinearity do the following: ``` inline bool IsCollinear(const Point64&...

> One comment: We need more tests, but my understanding based on the above discussion is that this is a compiler issue (clang) for a specific instruction set (aarch64), so...

This issue has reappeared in the latest commit, and I can't see why it has done so. Since I don't have any Apple devices I can't realistically debug it, so...

> @AngusJohnson Did you try to reproduce it like this: [#777 (comment)] No I didn't. Sorry. And looking at this problem again I can now see a very simple solution....

Thanks for the feedback. And yes this is definitely a bug that needs fixing.