| Sun Sep 22 06:03:06 2024 by Mizuki |
| Test: ./planet -M -o p.bmp < 1.txt 1.txt: 128 x @, 127 x . (total 255 characters) Result: https://i.postimg.cc/52Kc7kwm/p.png 1.txt: 128 x @, 128 x . (total 256 characters) Result: https://i.postimg.cc/wMpnRKp9/p1.png |
| Sun Sep 22 06:19:37 2024 by Mizuki |
| Line 1009: scanf("%255[\n]\n",cs); /* read line */ I believe that 255 is the issue...changing it to 1000 (in line with cs[1000]) solves it |
| Sun Sep 22 07:59:06 2024 by Mizuki |
| Line 1009: scanf("%255[\n]\n",cs); /* read line */ I believe that 255 is the issue...changing it to 1000 (in line with cs[1000]) solves it |
| Mon Sep 23 10:17:59 2024 by Torben |
| That is, indeed, probably the issue. I didn't consider map sketches that large. I'm rather busy this week, but I will update the files next week. |
| Mon Sep 23 14:36:11 2024 by Mizuki |
| Actually I'd probably switch that scanf 1000 to 999, as there's also a newline character - 1000 characters + 1 newline might overflow cs[1000] Also, the program can't seem to detect actual overflows, even when I tried to put a "if (Width > 1000) errors" condition. I wrote a printf line right before the Width checking condition to print the value of Width - result: line length: 1000 result of printf: 1000 line length: 1001 result: 1000 1 (an actual newline) line length: 2004 result: 1000 1000 4 it seems like the sscanf checks not only for 1000 characters, but also a newline (the \\r at the end) which results in some kind of "cap" for the value of Width even when an overflow occurs. Also, giving an empty file as sketch produce corrupted nonsense input. (""P" is not a valid character" as output - probably random character sequence) |
| Tue Sep 24 10:01:43 2024 by Torben |
| Sigh. I will look into it. The program was never intended as a robust industrial-strength application, so there are doubtlessly many such issues still. |
