Editor adds number sequence when line contains a 206 (DEFFN) code

[lippmaje]

The editor adds a number sequence (#14 plus 5 more bytes) in front of a comma whenever the source code contains the number 206. It also happens when the line number itself is made up from a 206 (lowbyte). See the sample below. Saving this sample and reloading it causes the unwanted number sequence(s) to reappear.

   5 REM False number bytes after a 206 data field.
   6 REM Does not happen with 205 or other numbers.
  10 DATA 206: REM a,b,c
  20 DATA 205: REM a,b,c
  30 DATA 206: REM a,
  40 DATA 206: REM ,b
  50 DATA 206: DATA "z,x",z,x: REM z,x
  60 DATA 207: DATA "z,","x,","z,x"
8900 REM Also happens if line nr contains 206, like
8901 REM with 8910 which is 34*256 + 206
8909 DATA "z,x"
8910 DATA "z,z,x"
8911 DATA "z,x"
9998 REM The number bytes prefix all commas of that line.
9999 REM If removed, they reappear after reload.

[lippmaje]

Hint: When you add a DEF FN statement to a program, the ZX basic system adds an empty number sequence (#14 plus 5 zeroes) to any parameter in the comma-separated parameter list. See ROM at $1F86. My assumption is that Basinc tries to mimick this behavior but fails to determine if the 206 is indeed a DEFFN or something else.

The issue may be caused by FindDEFFN() / ProcessDEFFN() in BASSupport.pas. I still have no clue how to compile the sources.

[ref-xx]

I could not be able to replicate the issue here (tested in 1.75, 1.78, 1.79).
(btw. please use latest version, 1.77 is outdated)

[lippmaje]

It would be great to be able to submit defects against the latest version. However, the last commit here is from Oct 21 v1.77. Do you update the GitHub project?

[ref-xx]

ok, I finally confirm and understand the problem. as you have perfectly pinpoint, both FindDEFFN() / ProcessDEFFN() was to blame.

[lippmaje]

v1.794

It looks like it happens again. Line 9422 is 36*256+206 and BasinC happily inserts 6 bytes into the DATA statement. Removing the chars and saving does not work because it gets added again as soon as you reload the program.

BAS file:
deffnbug.zip

[ref-xx]

I just want to report I didn't ignore the issue, but I'm working on a more complete fix now. it's not a hard problem but it needs too much grunt work that I wanted to avoid. I wish AI would help but no, it just generates nonsense.

[ref-xx]

I think I patched that by commenting out one line of code without going into rewriting the functions. It was caused by the bas file loading functions calling processdeffn for every line of basic. that was unnecessary. Now I'm forwarding the code lines to proper tokenizer. I try to test it to my best of knowledge but as sinclair basic is very flexible I don't know what may happen if you try to load an esoteric deffn function from a bas file. Anyway, I am temporarily closing this, hoping not opening it in the future.