Zitat:

---

Original von gni:

Zitat:

---

whose:
Zeiger auf UBYTE in ein ULONG "hineincastete" (worüber sich der GCC übrigens nicht wirklich beschwert hat, er schmiß nur die (verständliche) Warnung, daß man versucht, aus einem Zeiger einen Integerwert zu machen).

---

Wenn das per Cast geschieht, sollte der Compiler doch nicht meckern. Diese Warnung ist mir jedenfalls nicht untergekommen.

---

Zitat:

---

Genau das. Mit SAS/C kannst Du mit extern arbeiten. Bei GCC mußt Du ein #define nehmen, wenn Du mit -fbaserel arbeiten willst. Ansonsten wäre die Basis für den GCC eine normale Variable, die in der Datensektion liegt und die würde dann per Indexregister adressiert werden.

---

Zitat:

---

Zitat:

---

Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.

---

Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.

---

Ich werde Storm nie verstehen :-(
[/quote]

Ich nehme an, daß das als Zugeständnis an unsaubere Quellcodes gedacht war, die stillschweigend int mit 16Bit Breite annahmen. Allerdings frage ich mich auch, warum man das nicht wählbar gestaltet hat.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Wenn Du mit -Wall compilierst, sollte Dir die Warnung auch begegnen.

---

Zitat:

---

Oder hat der 3.x diese Warnung gar nicht mehr?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Wenn Du mit -Wall compilierst, sollte Dir die Warnung auch begegnen.

---

Genau das habe ich benutzt. Mit zusätzlichem -W gibts weitere Klagen.

---

Zitat:

---

Zitat:

---

Oder hat der 3.x diese Warnung gar nicht mehr?

---

Doch die gibt es noch. Und wenn die Prototypen alle stimmen, dann kommt es diese Warnung nicht.

---

Wenn man die "Warngrenze" heruntersetzt, meckert er auch nicht. Allerdings war es in diesem Zusammenhang ganz sinnvoll, daß die Warnung kam, sonst hätte ich diese "Tricks" u.U. gar nicht bemerkt.

So ganz habe ich diese Stellen in den Quellen noch nicht geblickt, aber die hängen mit der locale.library zusammen. Die Funktion, um die es sich dreht, heißt "getstring()". Rückgabetyp ist UBYTE *, wird allerdings öfter auf ULONG gecastet.

Sieht ein bißchen so aus, als wollte der Autor da Spielchen mit Kickstart 1.3 ermöglichen, aber das ist jetzt blanke Spekulation. Mal sehen, ob ich den Sinn der ULONG-Casterei nach den Aufräumarbeiten erfassen kann.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Die Funktion, um die es sich dreht, heißt "getstring()". Rückgabetyp ist UBYTE *, wird allerdings öfter auf ULONG gecastet.

---

Zitat:

---

Mal sehen, ob ich den Sinn der ULONG-Casterei nach den Aufräumarbeiten erfassen kann.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Die Funktion, um die es sich dreht, heißt "getstring()". Rückgabetyp ist UBYTE *, wird allerdings öfter auf ULONG gecastet.

---

Ich habe die Quellen und meine Änderungen bereits wieder gelöscht

---

Darf man fragen, welche Änderungen Du da genau vorgenommen hast?

Zitat:

---

Zitat:

---

Mal sehen, ob ich den Sinn der ULONG-Casterei nach den Aufräumarbeiten erfassen kann.

---

Da hast Du einiges vor, da die Quellen an allen Ecken und Enden mit ULONG-Feldern arbeiten.

---

Naja, da hoffe ich auf meine Intuition... wenn man einmal geschnallt hat, wozu ein Trick gut sein soll, ist das schon die halbe Arbeit

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Darf man fragen, welche Änderungen Du da genau vorgenommen hast? ;)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Darf man fragen, welche Änderungen Du da genau vorgenommen hast?

---

REG() Makros, <dos.h> + getreg() entsorgt, #ifndef,#define..#endif in de Headern, Forwards. Danach liessen sich die C Quellen mit dem GCC 3.3.3 übersetzen.

---

Ah, ok. Ich dacht schon, ich hätte etwas Gravierendes übersehen Danke.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Sodele, bin bei den Quellen mitten im Eingemachten.

Eine Sache gibts allerdings, die mich etwas irritiert. Da kommt in einer Datei der Funktionsaufruf

stpcpy()

vor, ist das ne SAS-eigene strcpy()-Funktion? Ich kenn mich mit den Standard-Bibliotheken nicht gar so gut aus, nur find ich stpcpy() in keinem Include, also gehe ich mal davon aus, daß diese Funktion SAS-spezifisch ist. Stimmt das?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 30.08.2005 um 11:48 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Da kommt in einer Datei der Funktionsaufruf

stpcpy()

vor, ist das ne SAS-eigene strcpy()-Funktion?

---

code:

---

char *stpcpy(char *dst,const char *src)  {
  do;while((*dst++=*src++)); return(--dst);
}

---

[ - Antworten - Zitieren - Direktlink - ]

@gni:

Danke Dir

Dann muß ich die noch an passender Stelle einfügen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:

Nein, das war ich nicht. Ich nehme an, daß Ilka den Port "schnell" erledigt hat, also ohne großes Aufräumen der Sourcen, denn das ist viel Arbeit.

Drei Viertel davon hab ich inzwischen geschafft, es war doch deutlich mehr Aufwand, als ich zuerst geschätzt hatte. Allerdings habe ich auch noch ein paar andere Sache laufen, so daß ich an FM2000 nur stundenweise arbeiten kann.

Ich hoffe, daß ich Mitte nächster Woche damit fertig bin, die Quellen aufzuräumen und ein erstes Kompilat davon zum Testen an Dich schicken kann.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:

Wenn Du nicht auf mein Ergebnis warten möchtest (gibt ein kleines Problem mit einer Funktion in clock.c, da streikt der 2.95.3, wird also noch etwas dauern), frag Ilkka doch mal, ob er Dir eine 68K-Version seines Ports erzeugt.

So ohne weiteres läßt sich der nämlich nicht für 68K compilieren, habe ich gerade festgestellt. Dazu müßte ich die Sourcen des Ports wieder anpassen, diesmal an die gewohnte Struktur der OS-Includes. Von der problematischen Funktion einmal ganz abgesehen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Du hast ja gesagt das er da gewisse sachen nicht
gemacht hat.
Ausserdem sind die MOSler meist so das die wenn dann
nur für MOS etwas machen.

---

Frag ihn halt mal, für ihn ists eigentlich nur ein simpler Compilerlauf. Allerdings mit seiner Compilerumgebung.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Keine Antwort nach 3 Tagen. Ich weiss ja auch nicht
ob er die Fehler beseitigt hat, steht nicht dabei.
Und wenn man das nur mit "seiner" umgebung Compilieren
kann...

---

Hm, das hatte ich befürchtet... naja, dann mußt Du Dich noch etwas gedulden, bis ich wieder Zeit finde, den Rest zu bearbeiten und zu compilieren.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]