I was using bwBASIC to count targets in a Makefile by checking for CHR$(9) in the left most column. It didn’t work. Examining the string returned by LINE INPUT #... showed the CHR$(9) had been swapped for " " (space)!?!? I don’t remember that happening. INPUT does some parsing to split values into variables.
A bunch of CRLFing later I ran the same code with QBasic and sure enough the CHR$(9) remained intact. The only thing LINE INPUT should do in the way of parsing/filtering is break at CRLF/LF and maybe the 255th char.
QBasic errors out with an Out of String Space error when too much data is read into a string. That could use some more testing since I believer QBasic allows strings longer than 255 chars.
Sample code:
10 CALL open("i", #1, "Makefile") : ct%=0 : targ%=0
20 while not eof(1)
30 line input #1, s$
40 if s$<>"" and left$(s$, 1)<>"#" then
50 ct%=ct%+1
55 '*ERR* bwBASIC is changing \t to ' '. =-O
60 if asc(s$)<>9 then targ%=targ%+1
70 END IF
80 wend
90 CALL close(#1)
100 print "Makefile stats:"
110 print "Lines: "; ct%
120 print "Targets:"; targ%
I was using bwBASIC to count targets in a Makefile by checking for `CHR$(9)` in the left most column. It didn't work. Examining the string returned by `LINE INPUT #...` showed the `CHR$(9)` had been swapped for " " (space)!?!? I don't remember that happening. `INPUT` does some parsing to split values into variables.
A bunch of CRLFing later I ran the same code with QBasic and sure enough the `CHR$(9)` remained intact. The only thing `LINE INPUT` should do in the way of parsing/filtering is break at CRLF/LF and maybe the 255th char.
QBasic errors out with an `Out of String Space` error when too much data is read into a string. That could use some more testing since I believer QBasic allows strings longer than 255 chars.
Sample code:
```
10 CALL open("i", #1, "Makefile") : ct%=0 : targ%=0
20 while not eof(1)
30 line input #1, s$
40 if s$<>"" and left$(s$, 1)<>"#" then
50 ct%=ct%+1
55 '*ERR* bwBASIC is changing \t to ' '. =-O
60 if asc(s$)<>9 then targ%=targ%+1
70 END IF
80 wend
90 CALL close(#1)
100 print "Makefile stats:"
110 print "Lines: "; ct%
120 print "Targets:"; targ%
```
Even though I wonder if there is some dialect of BASIC that requires the original odd behavior of LINE INPUT I’m closing this since it brings it into spec with what I remember and what I can test. A new bug can be created if someone knows where its now out of spec.
Even though I wonder if there is some dialect of BASIC that requires the original odd behavior of LINE INPUT I'm closing this since it brings it into spec with what I remember and what I can test. A new bug can be created if someone knows where its now out of spec.
I was using bwBASIC to count targets in a Makefile by checking for
CHR$(9)
in the left most column. It didn’t work. Examining the string returned byLINE INPUT #...
showed theCHR$(9)
had been swapped for " " (space)!?!? I don’t remember that happening.INPUT
does some parsing to split values into variables.A bunch of CRLFing later I ran the same code with QBasic and sure enough the
CHR$(9)
remained intact. The only thingLINE INPUT
should do in the way of parsing/filtering is break at CRLF/LF and maybe the 255th char.QBasic errors out with an
Out of String Space
error when too much data is read into a string. That could use some more testing since I believer QBasic allows strings longer than 255 chars.Sample code:
Looks like I have fixed this with commit
be6f888c9e
. In testing now.Even though I wonder if there is some dialect of BASIC that requires the original odd behavior of LINE INPUT I’m closing this since it brings it into spec with what I remember and what I can test. A new bug can be created if someone knows where its now out of spec.