#11 Sequential input corrupting data

Closed
opened 2 years ago by ChipMaster · 2 comments

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% ```
ChipMaster added the
blunder
label 2 years ago
ChipMaster self-assigned this 2 years ago
ChipMaster commented 2 years ago
Owner

Looks like I have fixed this with commit be6f888c9e. In testing now.

Looks like I have fixed this with commit be6f888c9e. In testing now.
ChipMaster added the
Maybe Fixed
label 2 years ago
ChipMaster removed the
Maybe Fixed
label 2 years ago
ChipMaster commented 2 years ago
Owner

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.
ChipMaster closed this issue 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.