mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
985b538e53
During an interactive drag of an arrow, it's possible to put the mouse pointer precisely on the pixel the arrow is pointing at. When that happens, draw_arrow computes the zero-length vector from the pointer to the target pixel, and tries to normalise it to unit length by dividing by its length. Of course, this leads to computing 0/0 = NaN. Depending on the platform, this can cause different effects. Conversion of a floating-point NaN to an integer is not specified by IEEE 754; on some platforms (e.g. Arm) it comes out as 0, and on others (e.g. x86), INT_MIN. If the conversion delivers INT_MIN, one possible effect is that the arrow is drawn as an immensely long diagonal line, pointing upwards and leftwards from the target point. To add to the confusion, that line would not immediately appear on the display in full, because of the draw_update system. But further dragging-around of arrows will gradually reveal it as draw_update rectangles intersect the corrupted display area. However, that diagonal line need not show up at all, because once draw_arrow has accidentally computed a lot of values in the region of INT_MIN, it then adds them together, causing signed integer overflow (i.e. undefined behaviour) to confuse matters further! In fact, this diagonal-line drawing artefact has only been observed on the WebAssembly front end. The x86 desktop platforms might very plausibly have done it too, but in fact they didn't (I'm guessing because of this UB issue, or else some kind of clipping inside the graphics library), which is how we haven't found this bug until now. Having found it, however, the fix is simple. If asked to draw an arrow from a point to itself, take an early return from draw_arrow before dividing by zero, and don't draw anything at all.
This is the README accompanying the source code to Simon Tatham's puzzle collection. The collection's web site is at <https://www.chiark.greenend.org.uk/~sgtatham/puzzles/>. The puzzle collection is built using CMake <https://cmake.org/>. To compile in the simplest way (on any of Linux, Windows or Mac), run these commands in the source directory: cmake . cmake --build . The manual is provided in Windows Help format for the Windows build; in text format for anyone who needs it; and in HTML for the Mac OS X application and for the web site. It is generated from a Halibut source file (puzzles.but), which is the preferred form for modification. To generate the manual in other formats, rebuild it, or learn about Halibut, visit the Halibut website at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.