Author |
Topic: Bug in loading a tkn file (Read 1134 times) |
|
BrianM
New Member
member is offline
Posts: 15
|
 |
Re: Bug in loading a tkn file
« Reply #5 on: May 1st, 2016, 1:18pm » |
|
Richard,
getting back to decoding tkn files. A line containing just a line number in a tkn file is created from a quote comment
e.g.
goto 100
...
100 ' a comment
results in the line
100
in the tkn file (actually no code is generated, just an entry in the labels table). It is not uncommon in legacy code to goto or gosub to a comment statement.
REM comments don't suffer from this as the REM keyword survives in the tkn file and hence generates code but the comment text is stripped.
For info: When decoding a tkn file, the processing for line numbers is the same as for character labels.
Note that line numbers in LB are really strings and not numeric. Line numbers 10 and 010 can be both used and are different.
Brian
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Bug in loading a tkn file
« Reply #6 on: May 1st, 2016, 4:05pm » |
|
on May 1st, 2016, 1:18pm, BrianM wrote:| When decoding a tkn file, the processing for line numbers is the same as for character labels. |
|
Clearly that's not the case in LBB, because otherwise the bug you reported (lines having only a line number being omitted, but lines having only a label not being omitted) would not occur! Do you have some 'inside knowledge' of how TKN files are encoded?
Quote:| Note that line numbers in LB are really strings and not numeric. Line numbers 10 and 010 can be both used and are different. |
|
In LBB line numbers are numeric (so 10 and 010 are the same) but labels are strings (so [10] and [010] are different). Internally they are handled quite independently, and indeed GOTO [100] is likely to execute much more quickly than GOTO 100! This arises because in BBC BASIC line numbers and labels are entirely different too.
As I alluded to before, I would have no idea how to modify the TKN decoder routine in LBB to fix the issue you reported. Specifically I don't know how lines containing only a line number are encoded in a TKN file. I would still contend that the circumstances in which the bug manifests itself are so rare - particularly in a program that has been 'compiled' to a TKN file - that it's of little importance.
Richard.
Edit: According to the LB Help documentation "Spaces and numbers are not allowed as part of branch label names" and the example is given of [1moreTime] as an invalid label. In practice it seems that digits are allowed, but perhaps this indicates that line numbers were once handled differently.
|
|
|
|
BrianM
New Member
member is offline
Posts: 15
|
|
Re: Bug in loading a tkn file
« Reply #7 on: May 1st, 2016, 9:19pm » |
|
Richard
I have no inside information. Many years ago (before LBB) I stumbled across a program on the internet which decoded tkn files into bas files. It is rather convoluted and far from correct. I converted this from quick basic to liberty basic and I occasionally try to improve it as I am not entirely happy with my program being 100% correct. Out of interest I compared the output from my program to that of LBB and it revealed deficiencies in both programs. I had thought that the LBB tkn decoder was based on the same program.
Line numbers in LB are strings, but is seems they are numeric in LBB. Try running this program in both LB and LBB.
gosub 10
gosub 010
end
10 print "10"
return
010 print "010"
return
I am not expecting you to modify the LBB IDE and as you say it is unlikely to be a problem with recent code. I am just reporting my findings. I am also happy to share with you my understanding of the tkn file format but it is not appropriate to do so in public.
Brian
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Bug in loading a tkn file
« Reply #8 on: May 1st, 2016, 9:43pm » |
|
on May 1st, 2016, 9:19pm, BrianM wrote:| I had thought that the LBB tkn decoder was based on the same program. |
|
No, I 'reverse engineered' the TKN format myself; the decoder is not based on anybody else's work. I think I know what program you are referring to, but I only came across it later (the User Name and Password decoding features that I subsequently added may have come from that program).
As far as I can see from my code (which was written several years ago) the presence of square brackets around branch labels is the only way they are recognised as such, so line numbers fundamentally won't be seen. I do not know how they are encoded.
Quote:| Line numbers in LB are strings, but is seems they are numeric in LBB |
|
I explained in my recent post how labels and line numbers are handled entirely differently in LBB. It cannot be adapted to be compatible with LB in this respect, because it is constrained by the way BBC BASIC works (line numbers are encoded as 16-bit binary integers, labels are represented as strings).
Richard.
|
|
|
|
|
