|
| 1 | +# Results of review and tests generated for the issues found. |
| 2 | + |
| 3 | +I prompted Claude as follows. It produced the tests in this directory, |
| 4 | +which I then tried with various results |
| 5 | + |
| 6 | + |
| 7 | +Here in/Users/jeff/go/src/github.com/maurymarkowitz/RetroBASIC/Review is a |
| 8 | + code review. Please make a plan to create tests that illustrate each of the critical review issues and that will fail until the issue is fixed. Name the tests so they are easy to correlate with the issues in the review. Create the tests in the Review directory. An ideal test is written in BASIC, but you may write a test in C if this is not possible |
| 9 | + |
| 10 | +## Note |
| 11 | + |
| 12 | +about `issue02_mat_fill_str_nonsquare.bas` |
| 13 | + |
| 14 | + Jeff, speaking to the AI: now when I run 1./retrobasic/Review/issue02_mat_fill_str_nonsquare.bas` it |
| 15 | + reports "Segmentation fault: 11". Don't fix this, just explain it, becauses |
| 16 | + it is useful as a report to the maintainer. |
| 17 | + |
| 18 | +⏺ The segfault is the bug in action. Here's what happens: |
| 19 | + |
| 20 | + The buggy loops are: |
| 21 | + for (int r = 1; r <= cols; r++) { // cols=3, so r goes 1,2,3 |
| 22 | + for (int c = 1; c <= rows; c++) { // rows=2, so c goes 1,2 |
| 23 | + int slot = r * (cols + 1) + c; // slot = r*4 + c |
| 24 | + |
| 25 | + For a DIM S$(2,3) matrix, the array is allocated for 2 rows × 3 cols. The |
| 26 | + valid slots (using r * (cols+1) + c) are: |
| 27 | + |
| 28 | + - (1,1)=5, (1,2)=6, (1,3)=7 |
| 29 | + - (2,1)=9, (2,2)=10, (2,3)=11 |
| 30 | + |
| 31 | + But the buggy loops iterate r up to 3 (cols) and c up to 2 (rows), so they |
| 32 | + compute: |
| 33 | + |
| 34 | + - (1,1)=5, (1,2)=6 ✓ |
| 35 | + - (2,1)=9, (2,2)=10 ✓ |
| 36 | + - (3,1)=13, (3,2)=14 ← out of bounds |
| 37 | + |
| 38 | + Slots 13 and 14 are past the end of the allocated array. The code then does |
| 39 | + free(destination_store->array[slot].string) on those garbage memory locations, |
| 40 | + and that's your segfault — it tries to free() whatever random pointer value happens to be sitting in unallocated memory. |
| 41 | + |
| 42 | + So the bug is actually worse than "wrong fill" — for any non-square matrix |
| 43 | + where cols > rows, it writes past the array boundary and crashes. The test as |
| 44 | + written is a valid demonstration: the maintainer will see it segfaults on a simple 2×3 string matrix fill. |
0 commit comments