Bug found: →

[Andy Dee]

Hello everyone

In a text block commented out with $If 0 - $EndIF, the control character "→" appears at some point. This causes PB 3.5 to assume that the file ends here, which is acknowledged with error 436 during compilation.
There used to be this bug with the "ü", but it was fixed quite quickly.
Perhaps of interest and use to someone.

Andy

Edit:
Dieser Fehler tritt auch beim Auskommentieren mit "'" oder "Rem" auf.

Edit 2 (sorry for German language):
This error also occurs when commenting out with “'” or “Rem”.

[Eric Pearson]

> the control character "→" appears at some point.

What character should (or previously did) appear at that point in the code?

[Dale Yarker]

just info, no conclusion offered or comment made

→ is OEM display of &h1A, &h1A is SUB / Ctrl-Z in ASCII, used as EOF in Windows and DOS.

Error 436 is #ENDIF expected ($ENDIF in PBDOS). The compiler would expect a $ENDIF before EOF

Ü is OEM display of &h9A, &h9A is SCI control code in ASCII (same binary as &h1A but has bit 7 set).

[Andy Dee]

PB 3.5 uses DOS-functions to get a files length.
I think, for speeding things up, PB 3.5 does not check, if ASCII Code 26 is inside of a file or at the end.
I wrote a small test.

Code:

$If 0
  Test zum Interpretieren       Test for interpreting the
  des ASCII-Zeichens 26.        ASCII character 26.
  PB 3.5 beendet das Lesen      PB 3.5 terminates the
  einer Datei, wenn dieses      reading of a file if this
  auftritt, sowohl die IDE      occurs, both the IDE and
  als auch der                  the command line compiler.
  Kommandozeilencompiler.       How does
  Wie reagiert                  Line Input, #iFile
  Line Input, #iDatei?          react?
$EndIf


$Dim All
$Lib All Off

Dim sFile As String , _                ' Name if File
    sText As String , _                ' Line of Text from sFile
    sTest As String , _                ' Last read text from sFile
    iFile As Integer, _                ' PB-Filenumber of sFila
    lFile As Long                      ' Number of Read Bytes (binary!)

sFile = "ifenantw.inc"
iFile = Freefile
lFile = 0
sTest = "$EndIf"

Open sFile For Input As #iFile

  Print "Length of ";sFile":";Lof(iFile)
  Shell "Dir "+ sFile

  Do:Loop Until Len(Inkey$)

  While Not Instr(sText,sTest)
    Print Using$("Read: ###### Bytes: ",lFile);
    Line Input #iFile, sText
    Incr lFile, Len(sText)            ' Add read textlength
    Print sText
    Incr lFile, 2                      ' Dos: Cr+Lf = 2 Byte for a new Line
  Wend

Close iFile

Output:

    D:\…\ascii26
    Length of ifenantw.inc: 20705
    Volume in drive D is (…)
    Directory of D:\…\[name]
    IFENANTW INC        20,705  03-11-25 10:48a
            1 file(s)        20,705 bytes
            0 dir(s)    46,846 Mega bytes free
    (…)
    Read:  1602 Bytes:    zugelassen werden sollen, z.B. ←,
    Read:  1642 Bytes:
    Error 62 at pgm-ctr: 485

The whole line is the following:

    zugelassen werden sollen, z.B. ←, →CHR$(26 = Pfeil nach rechts) oder Esc

PB-Help says:
    Error 62: Input past end

Good to know, that the Chr$()-function is to be used here.

Have later versions of PB[WIN|CC] got such a "fileterminator", too?

[Albert Richheimer]

Have later versions of PB[WIN|CC] got such a "fileterminator", too?

They have. The PBCC 6.0 documentation says:

It is assumed the data is standard text, delimited by a CR/LF ($CRLF) or EOF (1A hex or $EOF).  LINE INPUT# attempts to read the number of lines specified in the RECORDS rcds option, or the number of elements in the array, whichever is smaller.

And it works perfectly as described, see here: $EOF when using Line Input#

Cheers,
Albert

[Andy Dee]

So, one has only the chance to fix this miss of functionality by using the DOS-services and read up to 64 kb into a byte-array and use self written routines to manage the read an - maby - to written stuff.

Pointers and inline-asm would there be one possible way.
Another could be the set ob ARRAY-instructions…