🚀 go-pugleaf

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz)  meinte am 11.01.96
im Brett /DE/COMP/LANG/C++
zum Thema "Re: Segment-Terror ?"


>Kay Hayen (kay@edition.bonbit.org) wrote:
>> Ich habe gerade ein C Projekt auf Borland C++ 4.0x portiert und aergere
>> mich jetzt tierisch.
>>
>> Was habe ich verbrochen, um in "faralloc" eine Exception 13 zu ernten? Das
>> gleiche passiert auch bei malloc/calloc/farcalloc und soll laut Hilfe das
>> Ueberschreiten eines Segmentes angeben. Das verstehe ich jedoch nicht,
>> weil IMHO alloc einfach 0L zurueckgeben muss, wenn ein Fehler auftritt.
>
>Schmunzel :-)

>Ich nehme schwer an, dass das nicht ein Fehler von BC++, sondern von Dir
>ist. Eine Exception 13 (0x0D) ist eine allgemeine Schutzverletzung,
>vermutlich ueberschreibst Du irgendwo in Deinem Programm Speicher der Dir
>nicht gehoert.

Nein.

[ Beispiel fuer falsche Pointerverwendung geloescht ]

Gutes Beispiel, aber mein fehlerhafter Aufruf steht allein in einer Zeile  
und bekommt nur einen integer uebergeben. Ein Programmierfehler scheidet  
aus.

>Eine solche Schutzverletzung ist kein Aergernis, sondern eine der besten
>Erfindungen seitdem T.A.Edison die erste Gluehbirne gebaut hat: Sie macht
>Dich naemlich auf Fehler aufmerksam, die Du ansonsten nicht oder nur schwer
>entdecken wuerdest.

Ja, z.B. darauf, dass die StdLib des BCC 4.0 buggy ist. Entschuldige, aber  
da aergere ich mich gewaltig. Auf die Speicherverwaltung muss sich ein  
Programmierer wenigstens verlassen koennen.

>Normalerweise hilft Dir Dein Debugger, den Fehler zu lokalisieren, weil er
>naemlich das Programm an genau der Stelle anhaelt, an der der Fehler
>auftritt.

Eben innerhalb von malloc()/faralloc()/calloc().

>Im Falle von Fehlern in den Heap-Strukturen ist das aber meistens
>mitten im Code der RTL. Es gibt Software-Pakete, die malloc/free durch
>geaenderte Versionen ersetzen, wobei bei der Belegung/Freigabe bestimmte
>Checks durchgefuehrt werden (eigentlich gehoert die Verwendung eines solchen
>Paketes zur Pflichtuebung fuer jeden Programmierer).

Es ist Sache des BCC eine fehlerfrei RTL mitzubringen.

>Sowas kann man im uebrigen auch selber schreiben, wenn Du mehr wissen
>willst, dann kannst Du Dich gerne nochmal per Mail bei mir melden.

Werde ich jetzt selbst machen muessen, siehe unten.

>Zusammenfassung: Geh mal davon aus, dass der Fehler in Deinem Code liegt.

Also nein. Der Fehler ist Windows! Dieses Pracht-BS haelt fuer die  
Speicheranforderungen nur schlappe 6000 Pointer ( ein halbes Segment ? )  
bereit. Danach ist Schluss und die allen "*alloc" Routinen des BCC 4.0  
gemeinsame lowlevel Routine merkt nicht, das die Segmentgrenze verletzt  
wird. Eigentlich muesste sie das und einen Fehler melden, aber dieser  
Check war dann wohl zuviel.

Ich werde also meine vielen kleinen Anforderungen von einer eigenen  
Speicherverwaltung zusammenfassen und selbst verwalten lassen, ausserdem  
werden noch darauf abgestimmte new/delete Operatoren dazukommen muessen.

Folge war jetzt erstmal, dass ich das Projekt nach Linux portiert habe,  
wozu ich zwei Tools geschrieben habe.

Das erste konvertiert die DOS Pfadangaben in #include Anweisungen ins  
Linuxformat. Ich hab halt immer gerne alles in getrennten Verzeichnissen  
und da musste ich dann Pfade wie "G:\Pest\inc\include.h" verwenden, die  
ich bei ca. 25 includes und 15 sources natuerlich nicht von Hand aendern  
wollte, zumal dann #ifdef faellig geworden waeren, fuer den Fall, das ich  
wieder zu DOS zurueckkehren will. So kann ich die gleichen unveraenderten  
sources mit einer zusaetzlichen Zwischenstufe im Makefile auch mit dem gcc  
uebersetzen, editiert werden die Originale.

Das zweite ersetzt die autodependancies des BCC. Es scant ein source und  
dessen includes und deren includes usw., ob es ein include findet, das  
neuer ist als dieser source, der es liest. Wenn ja wird ein touch  
losgelassen. Das minimiert die Compiles ein wenig, sonst muesste mensch  
entweder das makefile staendig anpassen, wenn neue Abhaengigkeiten  
entstehen oder im Zweifel zuviel uebersetzen.

Als naechstes steht ein mkmake auf dem Plan, es soll aus den sourcefiles  
selbst ein Makefile erstellen und warten. Sowas gibt es alles sicher  
schon, aber wer Interesse oder Anregungen hat kann sich ja mal melden, ich  
poste das gerne in dieses Brett, ist sehr kurz.

>Gruss
>
>        Uz

        Mensch liest sich, Kay


--
** *Kurze* Signaturen sind die besten **