Bug
2. Fehler/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 3)

English


Fehler (Bug's)/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 1)
Fehler (Bug's)/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 2)

2.25. Der Fehler "File not found" nach Verwendung von NAME

Versionen: 3.0/3.1/3.2
bekannt : Fehler in Version 3.50 beseitigt

Ein sehr merkwürdiger Fehler in der Behandlung PowerBASIC-interner Filehandles hat sich bei der Verwendung des Befehles "NAME" eingeschlichen. 
    Beispiel:
           OPEN "B",1,"DATEI1.TMP"       ' Öffnen der 1. Datei
           OPEN "B",2,"DATEI2.$$$"       ' Öffnen
           CLOSE 2                       ' ... und sofort schliessen
           OPEN "B",3,"DATEI3.TMP"       ' Öffnen
           CLOSE 3                       ' ... und sofort schliessen
           KILL "DATEI2.$$$"             ' 2. Datei löschen
           NAME "DATEI3.TMP" AS "DATEI2.$$$"
                                         ' 3. Datei -> 2. Datei umbenennen
           CLOSE 1                       ' ... Schliessen der 1. Datei
           END

2.26. Rechenfehler bei der Verwendung von Konstanten

Versionen: 3.0/3.1/3.2
bekannt : nein
PowerBASIC rechnet bei der Verwendung von Konstanten gelegentlich nicht korrekt. Es sei natürlich die Frage in den Raum gestellt, warum man nicht gleich das Rechenergebnis einsetzt, da es sich hierbei um eine reine Formsache handelt. 
    Beispiel:
           i% = -20-4   : %k= -20-4
           PRINT i%     , %k

2.27. falsches "Bit schieben" bei ROTATE

Versionen: 3.0/3.1
bekannt : Fehler in Version 3.20 beseitigt

Der ROTATE-Befehl hat in PowerBASIC 3.0/3.1 einen Fehler sofern Variablen vom Type QUAD verwendet werden. 
    Beispiel:
           i&& = 1
           ROTATE RIGHT i&&, 1
           ROTATE LEFT i&&, 1
           PRINT i&&

2.28. Overflow bei Verwendung von FOR/NEXT-Schleifen

Versionen: 3.0/3.1/3.2/3.5
bekannt : ja

PowerBASIC erlaubt es nicht in FOR/NEXT-Schleifen den maximal gültigen Wertebereich einer Variablen auszuschöpfen. Der maximal mögliche Wert wird intern von PowerBASIC verwendet, da PowerBASIC m.E. erst intern die Variable erhöht und dann abfragt. Logischerweise kommt es dabei zu einem Überlauf, sofern Ihr Wert bereits den maximal möglichen Wert erreicht hat.
Der Fehler betrifft m.E. alle Variablentypen. 
    Beispiel:
           FOR Demo? = 1 TO 255
               PRINT Demo?
           NEXT Demo?
Sollten Sie nicht die "$ERROR NUMERIC" Bibliothek verwenden, so befindet sich diese FOR/NEXT Konstruktion in einer Endlosschleife.

Dieser Effekt ist begründet aufgrund der Abwärtskompatibilität zu anderen BASIC Compilern und der Wirkungsweise der Intel CPU.

2.29. Overflow bei Verwendung von STEP -1 in FOR/NEXT-Schleifen

Versionen: 3.0/3.1/3.2/3.5
bekannt : ja

In PowerBASIC müssen alle Variablen vom gleichen Typ (signed/unsigned) sein, sofern sie in FOR/NEXT Schleifen verwendet werden. Folgendes Beispiel ist also nicht zuläßig: 
    Beispiel:
           FOR Demo?? = 10 TO 2 STEP -1
           NEXT Demo??

    oder
           FOR Demo??? = 10 TO 2 STEP -1
               PRINT Demo???
           NEXT Demo???
Sollten Sie nicht die "$ERROR NUMERIC" Bibliothek verwenden, so befindet sich diese FOR/NEXT Konstruktion in einer Endlosschleife.

2.30. Der Bug im VARPTR32-Befehl

Versionen: ab 3.2
bekannt : Fehler in Version 3.50 beseitigt

Im Gegensatz zu den Befehlen STRPTR32 und CODEPTR32 hat sich im VARPTR32-Befehl ein Bug eingeschlichen. Leider ist es mit diesem Befehl nicht möglich gleichzeitig eine mathematische Operation auszuführen. 
    Beispiel:
           DIM Demo AS STRING * 10
           Wert1??? = VARPTR32(Demo) + 1
           Wert2??? = VARPTR32(Demo)
           Wert2??? = Wert2??? + 1
           PRINT  Wert1???, Wert2???

2.31. Der "KEY ON" Bug

Versionen: 3.0/3.1/3.2
bekannt : nein

Laut PowerBASIC Benutzerhandbuch und BASIC Spezifikation des KEY-Befehls stellt der 'KEY ON'-Befehl in Zeile 25 die aktuelle KEY-Tastaturbelegung in 'Norton Commander' ähnlicher Form dar. Ist dieses der Fall, sollte PowerBASIC jeden Zugriff des Programmierers auf die Zeile 25 durch LOCATE mit einem 'Error 5: Illegal Function' unterbinden. Ebenso sollte die Zeile 25 durch ein versehentliches Scrollen geschützt sein. Seit PowerBASIC V3.x (im Gegensatz zur V2.10) ist dieses nicht mehr der Fall! 
    Beispiel:
            KEY OFF
            FOR i% = 1 TO 10
                READ A$
                KEY i%, A$ + CHR$(13)
            NEXT i%
            KEY LIST
            COLOR 3, 0
            KEY ON
            COLOR 7, 0
            LOCATE 25, 1: PRINT " Dieser Text sollte abgefangen werden!! ";
            WHILE NOT INSTAT
            WEND
            KEY OFF
            END
            DATA "Hilfe", "Return"', "Edit", "Wechseln", "Report"
            DATA "PRINT", "Setup", "DOS", "Kopie", "Quit"
Mir stellt sich nun die Frage ob dieses ein Fehler im PowerBASIC-Handbuch oder ein Bug im Compiler ist. Auf alle Fälle können Sie diesen Effekt aber durch die Verwendung von: 
            VIEW TEXT (1,1)-(80,24)
umgehen.

2.32. Absturz der PowerBASIC IDE im Pick-Menü

Versionen: 3.0/3.1/3.2/3.5
bekannt : nein

Die PowerBASIC IDE stürzt ab, wenn sie zum ersten Mal nach dem Start der IDE im Menü "File\Pick", anstatt der RETURN-Taste die DEL-Taste betätigen. Sollten Sie bereits während der Sitzung das Menü "Pick" einmal mit RETURN geöffnet haben, so wirkt sich der Fehler nicht mehr aus. Ich persönlich halte den Fehler für sehr ernsthaft, liegen doch die beiden Tasten auf der Tastatur eng zusammen.

2.33. Absturz der PowerBASIC IDE bei fehlerhaften Syntax

Versionen: 3.0/3.1/3.2
bekannt : Fehler in Version 3.50 beseitigt

Die PowerBASIC IDE stürzt ab, sofern Sie versuchen folgende Zeile zu compilieren: 
            PRINT Test1$ XOR Test2$ XOR Test3$
Über den Sinn der Zeile möchte ich lieber nicht diskutieren. {g}

2.34. falsches Vertauschen der Variablen bei Verwendung von SWAP

Versionen: 3.0/3.1/3.2
bekannt : nein

Bei Verwendung des SWAP-Befehl in Verbindung mit TYPE-Strukturen und der Indizierung des Feldes über eine Variable (im Beispiel "a(c%).x") werden die Felder falsch miteinander getauscht (geswappt). Wird das Feld über einen fest definierten Wert (z.B. "a(1).x") indiziert, dann arbeitet der SWAP-Befehl korrekt. 
    Beispiel:
            TYPE SwapTest                 ' Benutzerdefinierter Datentyp
                x AS INTEGER
                y AS INTEGER
            END TYPE

            DIM a(1 TO 2) AS SwapTest     ' Array anlegen

            c%     = 1
            d%     = 2
            a(1).x = 1                    ' Felder initialisieren
            a(1).y = 2
            a(2).x = 3
            a(2).y = 4
            CLS
            PRINT "vor  SWAP: "; a(c%).y, a(d%).y
            SWAP                 a(c%).y, a(d%).y
            PRINT "nach SWAP: "; a(c%).y, a(d%).y

2.35. Der Multiplexer Interrupt Fehler im REG-Befehl

Versionen: 2.x/3.0/3.1/3.2
bekannt : Fehler in Version 3.50 beseitigt

Erstaunlicherweise gibt es selbst einige Ungereimtheiten sofern Sie mit dem REG-Befehl den Multiplexer-Interrupt &h2F aufrufen. In der Regel hat es den Anschein das der Aufruf vom System abgewiesen wird. Ein Gegentest beweist aber das es mit dem Inline-Assembler funktioniert! Beobachtet wurde dieser Effekt bei der Programmierung des MSCDEX, der Abfrage der Windows-Version und der Timeslice-Funktion des Multiplexer- Interrupts.
Abhilfe schafft nur konsequentes Programmieren mit dem Inline-Assembler. 
    Beispiel:
            ! mov ax, &h1680
            ! int &h2F
            ! mov Taskfreigabe%, ax
            Taskfreigabe% = Taskfreigabe% AND 255
            SELECT CASE Taskfreigabe%
                CASE &h80 : PRINT "Taskfreigabe nicht unterstützt"
                CASE &h0  : PRINT "Taskfreigabe wird unterstützt"
                CASE ELSE : PRINT "unerwarteter Wert"
            END SELECT

            REG 1, &h1680
            CALL INTERRUPT &h2F
            Taskfreigabe% = REG(1)
            Taskfreigabe% = Taskfreigabe% AND 255
            SELECT CASE Taskfreigabe%
                CASE &h80 : PRINT "Taskfreigabe nicht unterstützt"
                CASE &h0  : PRINT "Taskfreigabe wird unterstützt"
                CASE ELSE : PRINT "unerwarteter Wert"
            END SELECT
Die Ursache für diesen Effekt liegt in der Wirkungsweise des REG-Befehls begründet, allerdings hat QuickBASIC diese Probleme nicht. {g}

2.36. Inhalt eines Verzeichnis wird mit KILL gelöscht

Versionen: 3.0/3.1/3.2
bekannt : nein

Ein nettes Feature verbirgt sich in dem KILL-Befehl von PowerBASIC. Sollten Sie die Pfadangabe mit einem Backslash (ohne weitere Wildcards oder Dateinamen abschliessen), dann wird das komplette Verzeichnis gelöscht. 
    Beispiel:
           KILL "C:\TEMP\"               ' löscht alle Dateien im TEMP-
                                         ' Verzeichnis

2.37. Die Sache mit der Zeichenkette "USR"

Versionen: 3.0/3.1/3.2
bekannt : Fehler in Version 3.50 beseitigt

Ein völlig unerklärliches Verhalten in der PowerBASIC-IDE und dem Kommandzeilen-Compiler ist zu beobachten, wenn die Zeichenkette 'USR' in der Source vorkommt. Da der Compiler im ersten Beispiel abstürzt, ist definitiv von einem Bug zu sprechen. 
    Beispiel:
           PRINT USR                     ' PB/PBC stürzt ab
           Test% = USR                   ' Error 477

2.38. Der GOTO DWORD Bug

Versionen: 3.2
bekannt : beseitigt in Version 3.50

PowerBASIC vergißt ganz simpel den Segmentanteil der Adresse, that's all. 
    Beispiel:
            Demo??? = CODEPTR32(TestLabel)
            GOTO DWORD c???
            $SEGMENT
            TestLabel:
            PRINT "Test"
            END

2.39. Der 'ON LOCAL ERROR' Bug

Versionen: 3.0/3.1/3.2
bekannt : beseitigt in Version 3.50

Bei Verwendung von 'ON LOCAL ERROR' in einer PBU kann zu einem Absturz des Programms führen. 
    Beispiel:
            'Main file
            $COMPILE EXE
            $LINK "TEST.PBU"            'oder PBL
            FileName$ = "TEST.DOC"
            CALL ResumeDemo(Demo%)
            PRINT "Error", Demo%
            END

            'Unit file
            $COMPILE UNIT
            SUB ResumeDemo (Demo%) PUBLIC
                ON LOCAL ERROR RESUME NEXT
                ' Zum Test dieses File mit Winword etc. erstellen und einmal
                ' abspeichern
                OPEN "TEST.DOC" FOR BINARY AS #1
                Demo% = ERRTEST
            END SUB

2.40. ... und nochmal 'ON LOCAL ERROR'

Versionen: 3.0/3.1/3.2/3.5
bekannt : nein

PowerBASIC stürzt ab, wenn in einer SUB/FUNCTION mit "ON ERROR" anstatt mit "ON LOCAL ERROR" gearbeitet wird. In diesem Fall kann es zu einem Stack bzw. Stringspeicher Problem kommen, sofern der erwartete Fehler auch eintritt.
Natürlich ist dies ein eindeutiger Programmierfehler, aber der Compiler sollte dieses bereits beim compilieren erkennen.

2.41. Laufzeitfehler im PowerBASIC Helpcompiler

Versionen: 3.0 (Helpcompiler)
bekannt : nein

Der Helpcompiler (bzw. Encoder) scheint irgendwie reichlich Fehler zu enthalten. Vor allem Anfängern bereit der Laufzeitfehler 9 an der Adresse 10095 bestimmt viel Ärger. Dies ist ein interner Fehler des Helpcompilers, der durch das Nichtvorhandensein des Befehls '/LOOKUP' ausgelöst wird.

2.42. Der Fehler Truncating im PowerBASIC Helpcompiler

Versionen: 3.0 (Helpcompiler)

Der Fehler 'Truncating ... to 76 characters' wird des öfteren irrtümlich angezeigt, da die Steuerzeichen nicht berücksichtigt werden.

2.43. Absturz der PowerBASIC-IDE nach Aufruf der eigenen Hilfe

Versionen: 3.0 (Helpcompiler)

Bei der Programmierung bzw. eigentlich dem Schreiben der Hilfe müssen Sie aufpassen, das die effektive Länge der darzustellenden Textzeile nicht größer als die wirklich vorhandene Zeilenbreite des PowerBASIC- Hilfefensters ist, da die PowerBASIC-IDE in diesem Fall mit einem Grafikfehler abstürzt.
Dieser Fehler tritt nur in der Endwicklungsphase einer selber geschriebenen Hilfedatei (*.PBH) auf!


Fehler (Bug's)/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 1)
Fehler (Bug's)/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 2)


(c) 1995/2007 by Thomas Gohel, All rights and bug's reserved