Bug found: → - Printable Version

PowerBASIC Users Meeting Point

Bug found: → - Printable Version

+- PowerBASIC Users Meeting Point (http://pump.richheimer.de)
+-- Forum: User to User Discussions (http://pump.richheimer.de/forumdisplay.php?fid=3)
+--- Forum: PowerBASIC for DOS (http://pump.richheimer.de/forumdisplay.php?fid=6)
+--- Thread: Bug found: → (/showthread.php?tid=46)

Bug found: → - Andy Dee - 03-07-2025

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”.

RE: Bug found: → - Eric Pearson - 03-10-2025

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

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

RE: Bug found: → - Dale Yarker - 03-11-2025

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).

RE: Bug found: → - Andy Dee - 03-11-2025

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:

Quote: 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:

Quote: 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?

RE: Bug found: → - Albert Richheimer - 03-12-2025

(03-11-2025, 02:58 PM)Andy Dee Wrote: Have later versions of PB[WIN|CC] got such a "fileterminator", too?

They have. The PBCC 6.0 documentation says:

Quote: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

RE: Bug found: → - Andy Dee - 03-12-2025

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…