Package: bsdgames
Version: 2.17-28
Severity: normal
Dear Debian maintainers,
I was playing the old Trek game from the Debian bsdgames package, and
I've identified a bug. I've patched it on my system, and the patch
solves the problem. I sent a merge request to Debian Salsa about 6
months ago with the complete patch, but never got a response from that.
Let me know if I am submitting the patch incorrectly, or if I can do
anything else to help you out. I haven't contributed to Debian packages
before, so I apologize if I'm not following the protocol correctly.
The bug:
When using the visual command in trek, the game should print the content
of the three ship-adjacent squares that are closest to the view
direction specified. So, if the player is at the coordinates 7,3/5,5 and
types "visual 0", they should see the following:
4,4 . . * 4,6
where 4,4 is the coordinate of the leftmost viewed location, 4,6 is the
rightmost viewed location, and . . * represent empty space, empty space,
and a star. Unfortunately, this currently does not occur. When the
player looks in the downward directions, the view is as expected, but
when looking upward, some spaces are replaced with a ? character and
some coordinates are printed incorrectly -- the incorrect coordinates
are of the form "255 + ship position". So, in the above case, the player
would see the following:
260,260 ? ? ? 260,6
The explanation:
The bug is caused by an integer overflow in the 'visual.c' file. The
struct xy, defined in trek.h, uses a pair of unsigned char to hold x,y
coordinates for the position of starbases in quadrants in kill.c and for
the position of sectors relative to the ship in visual.c. This works
fine in kill.c, where the unsigned chars are used to store absolute
positions that are always positive, but in visual.c, the unsigned chars
roll over to 255 when they are set to a value of -1, which they are in
all the cases where a sector is above or to the left of the ship. This
causes the coordinate values to be incorrect, as above, and for the
visual command to fail to correctly print all sectors affected by this bug.
My testing indicates that this is fixed by simply changing unsigned char
to char in trek.h. No uses of struct xy that I know of require numbers
greater than 7 (the highest number in the quadrant axes), so switching
to char and losing the ability to store numbers in the range 128-255
should not be problematic.
The patch:
--- debian/bsdgames/trek/trek.h 2019-12-18 10:12:35.003133958 -0700
+++ jgbaldwinbrown/bsdgames/trek/trek.h 2019-12-18 10:04:23.612000795
-0700
@@ -201,7 +201,7 @@
struct xy
{
- unsigned char x, y; /* coordinates */
+ signed char x, y; /* coordinates */
};
I am using Debian GNU/Linux 10 (Buster) and Linux kernel 4.19.0-9-amd64
in a virtual machine for testing.
Best,
Jim
