Bugliste des SyncML-RTK vom 06.03.2001 durch Mirko Mrowczynski
Stand 03.12.2001

Fehlerbeschreibung: undefined reference to "ltoa"

Die Bibliotheksdatei libxpthttp.so lässt sich nicht compilieren, weil in der 
Datei /syncml/xpt/bindings/http/all/xpt-http.c in Zeile 1597 eine Funktion 
"ltoa(..)" aufgerufen wird die nicht definiert ist.

Lösung:

folgende Funktion direkt vor Zeile 1597 einfügen.

char *ltoa(long val,char *buf,int base) {
  ldiv_t r;
  if (base > 36 || base < 2)
  {
    *buf = '\0';
    return buf;
  }
  if (val < 0)
  *buf++ = '-';
  r = ldiv (labs(val), base);
  if (r.quot > 0)
  buf = ltoa ( r.quot, buf, base);
  *buf++ = "0123456789abcdefghijklmnopqrstuvwxyz"[(int)r.rem];
  *buf   = '\0';
  return buf;
} 

Die Funktion "ltoa" (long to ascii) wird nur einmal mit Basis 16 aufgerufen.
Es wäre also gar nicht nötig eine Funktion die mit Basen zwischen 2 und 36 
arbeiten kann zu verwenden.

----------------------------------------------------------------------------- 

Fehlerbeschreibung: "get" im Parser

Wird ein SyncML-Dokument geparst, das einen "get" Befehl enthält, dann wird
das Parsen mit Fehler 0x200b (ungültiges Dokument) abgebrochen. Der "get"
Befehl ist im Parser nicht realiesiert.

Lösung:

switch - Anweisung um "get" Eintrag erweitern. Aufruf der Callbackfunktion
hinzufügen.

----------------------------------------------------------------------------- 

Fehlerbeschreibung: xptReceiveData(..) Kommunikationsstatus

Wenn diese Funktion nur einmal aufgerufen wird, dann wird der
Kommunikationsstatus der Verbindung über die Daten übermittelt werden nicht
geändert.
Die Definition des Kommunikationsstatus erfolgt in der Datei
syncml/src/xpt/manager/all/xptcomm.c ab Zeile 117:
#define CI_STATE_READY_FOR_EXCHANGE       1 // Connection just opened
#define CI_STATE_EXPECTING_SET_DOC        2 // Client exchange just initiated
#define CI_STATE_EXPECTING_GET_DOC        3 // Server exchange just initiated
#define CI_STATE_SENDING                  4 // Okay to send data
#define CI_STATE_RECEIVING                5 // Okay to receive data
#define CI_STATE_EXPECTING_END_EXCHANGE   6 // Sending/receiving finished

Der Status ist beim Aufruf von xptReceiveData(..) 5 und soll beim Server auf 
den Wert 2 und beim Client auf den Wert 6 gesetzt werden. Das erfolgt aber 
nicht beim ersten Aufruf von xptReceiveData(..).
Wurde der Status nicht geändert liefern folgende xpt..-Funktionsaufrufe
Fehler 0x5017 (ungültiger Kommunikationsstatus)

Die Fehlercodes stehen in der Datei syncml/src/xpt/manager/xpt.h und werden
dort "berechnet". Die Suche nach einer Fehlernummer bleibt daher erfolglos.

Lösung:

xptReceiveData(..) muss nachdem die Daten empfangen wurden noch einmal
aufgerufen werden. Diesmal ohne Daten zu empfangen.

Beispiel:
..
dataLen = 0;
ret = xptReceiveData(pConn, writePtr, freeBytes, &tmpdataLen);
while (tmpdataLen>0) {	//solange beim letzten Aufruf Daten empfangen wurden
  dataLen = dataLen + tmpdataLen;
  freeBytes = freeBytes - tmpdataLen;
  ret = xptReceiveData(pConn, (writePtr+dataLen), freeBytes, &tmpdataLen);
}
..
----------------------------------------------------------------------------- 
Fehlerbeschreibung: xptReceiveData(..) empfängt falsche Daten

In einem Teil aller Kommunikationsversuche stehen ab der Position, die von
xptReceiveData(..) an die Applikation übergeben wurde, falsche Daten.

Lösung:

In der Datei syncml/src/xpt/bindings/http/all/xpt-http.c sind ab
einschliesslich Zeile 1935 6 Zeilen auskommentiert. (Eventuelle Verschiebung
durch ltoa Problem beachten). Werden die Kommentare entfernt und das Toolkit
neu compiliert, dann liefert xptReceiveData(..) richtige Daten.
----------------------------------------------------------------------------- 

Fehlerbeschreibung: smlTerminateInstance(id) Listenfehler

Angelegte Workspaces werden im RTK als Liste verwaltet. Die Applikation
erhält nach dem Erzeugen des Workspace einen ganzzahligen Wert >=1 zur
Identifikation.
Wird mit smlTerminateInstance(id) ein Workspace aus der Mitte der Liste
gelöscht, dann entsteht ein Fehler in der Liste.

Beispiel:

..
smlInitInstance(&callbacks, &options, NULL, &id4reply);	//id4reply=1
..
smlInitInstance(&callbacks, &options, NULL, &id);	//id=2
..
smlTerminateInstance(id4reply);
..
smlInitInstance(&callbacks, &options, NULL, &id4reply);	//id4reply=2
/* Hier also 2 Workspaces mit gleicher ID ! */
..
smlTerminateInstance(id);
..
smlInitInstance(&callbacks, &options, NULL, &id);	//id=0
/* ID=0 ist Fehler, da 0. Listenelement */
..
smlProcessData(id, SML_ALL_COMMANDS);			//Segmentation fault.

Lösung:

Workspaces in der Reihenfolge beenden, in der sie erzeugt wurden.

Beispiel:

..
smlInitInstance(&callbacks, &options, NULL, &id4reply);	//id4reply=1
..
smlInitInstance(&callbacks, &options, NULL, &id);	//id=2
..
smlTerminateInstance(id);
..
smlTerminateInstance(id4reply);
..
smlInitInstance(&callbacks, &options, NULL, &id4reply);	//id4reply=1
..
smlInitInstance(&callbacks, &options, NULL, &id);	//id=2
..
Bei meiner Implementation war das möglich. Es kann aber Applikationen geben,
wo das nicht funktioniert.