GTKTerm 0.99.5 hat einen Bug eingebaut.

Betrifft den HEXVIEW-Modus!
Problem ist, daß beim einlesen von Bytes alles gut geht bis ein 0x00
kommt.

In meinem Fall habe ich 0x80 0x00 0x01 0x00 via RS232 gesendet und
GTKTerm brachte u. a. sowas raus: 0x80 0x00 0xC3 0x11

Schuld ist eine Funktion, die eizelne Bytes von einem Quell- in einen
Zielstring kopiert, und zwar solange, bis ein 0-Byte (0x00) aufkreuzt.
Dann ist's vorbei mit kopieren und der Rest ist irgendnen Datenkrams.

Wer dennoch GTKTerm benutzen will ohne diesen Bug, ändert im Quellcode,
File "src/buffer.c", Zeile 61, von

buffer_tmp = g_string_new(chars);

in

buffer_tmp = g_string_new_len(chars, size);

um, dann nochmal make drüberrattern lassen (evtl. noch ./configure falls
noch nicht gemacht) und fertig.

Als Dateianahng so eine abgewandelte Version.

Gruß
 Hegy

Noch ein Nachtrag zum vorangegangenem Posting und der angefüchten Datei.
Defaultmäßig habe ich da den Hex-View Modus eingestellt statt
ASCII-View. Läßt sich aber nach wie vor umschalten.

Heute war richtiges Scheißwetter, also mal GtkTerm weiter
"entschrottet".
Ein Bug ist z.B. noch der, daß beim Hex-View die Werte durcheinander
dargestellt werden (s. Anhang). Weiter unten dann noch eine
funktionsfähige Variante.

Hier jetzt mal die neue Variante. Ich habe auch gegengecheckt, ob alle
Bytes auch dargestellt werden und nicht überschrieben werden. Da habe
ich auf die schnelle nichts festgestellt, dennoch, ohne Garantie.

Und zum Schluß die lauffähige Version. Wer selber den Fehler wegändern
will, er liegt hier:

Im Archiv File src/widgets.c, Zeile 363 ff. Funktion put_hexadecimal().
Bug: Wenn der Cursor im Term-Fenster auf Spalte 0 steht, wird auch die
Bytezählvariable 'bytes' auf 0 gesetzt, obwohl von der vorangegangenen
Zeile noch Bytes geschrieben worden sind. Bsp.: In Zeile 1 werden nach
und nach im 16-Byte-Modus (16 Byte = 1 Zeile) 14 Byte reingeschrieben.
Jetzt kommt der nächste Datensatz, der aus 5 Bytes besteht. 2 Bytes
werden in Zeile 1 geschrieben, dann automatisch wird in Zeile 2 der Rest
reingeschrieben, also 3 Bytes. Die Var. 'bytes' wird dann aber auf 0
gesetzt und die jetzt nachfolgenden Bytes werden von 0 an gezählt,
obwohl schon 3 Bytes in der Zeile stehen, daher kommt es zum Versatz von
3 Bytes in Zeile 2. Sieht dann so aus:

Zeile 1: xx xx xx xx xx xx xx xx - xx xx xx xx xx xx B1 B2
Zeile 2: B3 B4 B5 xx xx xx xx xx xx xx xx - xx xx xx xx xx xx xx xx

Die geänderte Funktion hierzu:

void put_hexadecimal(gchar *string, guint size)
{                                              
  static gchar data[128], data_byte[6];
  static guint bytes;                  
  glong column, row; 
  gint i = 0;       
             
  if(size == 0)
    return;    
           
  while(i < size)
  {              
    while(gtk_events_pending()) gtk_main_iteration();

    vte_terminal_get_cursor_position(VTE_TERMINAL(display), &column, &row);

    // diesen Teil habe ich umgestellt, da wurde der Fehler deutlich.
    // ursrünglich hieß es
    // if(show_index)
    // {
    //     if(column == 0)
    //         /* First byte on line */
    //  usw.
    if(column == 0) /* First byte on line */
    {                                       
      //bytes = 0; hier war der Hund begraben
      if(show_index)
      {
        sprintf(data, "%6d: ", total_bytes);
        vte_terminal_feed(VTE_TERMINAL(display), data, strlen(data));
      }                                                              
    }  
     
    /* Print hexadecimal characters */
    data[0] = 0;

    while(i < size) // war: while(bytes < bytes_per_line && i< size)
    {
      gint avance=0;
      gchar ascii[1];
      
      sprintf(data_byte, "%02X ", (guchar)string[i]);
      //printf("%02X ", (guchar)string[i]);
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, 3);
      
      avance = (bytes_per_line - bytes) * 3 + bytes + 2;
      
      /* Move forward */
      sprintf(data_byte, "%c[%dC", 27, avance);
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, strlen(data_byte));
                                                                             
      /* Print ascii characters */                                           
      ascii[0] = (string[i] > 0x1F) ? string[i] : '.';
      vte_terminal_feed(VTE_TERMINAL(display), ascii, 1);
      
      /* Move backward */
      sprintf(data_byte, "%c[%dD", 27, avance + 1);
      vte_terminal_feed(VTE_TERMINAL(display), data_byte, strlen(data_byte));
                                                                             
      if(bytes == bytes_per_line / 2 - 1)                                    
      {
        vte_terminal_feed(VTE_TERMINAL(display), "- ", strlen("- "));
        //printf("- ");
      }
      
      bytes++;
      i++;
      
      /* End of line ? */
      if(bytes == bytes_per_line)
      {
        vte_terminal_feed(VTE_TERMINAL(display), "\r\n", 2);
        total_bytes += bytes;
        bytes = 0;
        //printf("\n");
      }
    }
  }
}

Alerdings bleibt die zusammengestauchte Ansicht bei der 24/32-Byte
Darstellung, da hilft nur ein gaaaaaanz breites Term-Fenster. Oder
Mikro-Schrift.

Mit der obigen Version ist auch ein Fehler reingekommen.... kommt davon,
wenn man sein eigenen Krmas nicht selber mal chekkt. Die Index-Nummern,
die wahlweise eingeschaltet werden können, sind flöten gegangen. Aber
jetzt sindse wieder da.

Unter

vte_terminal_get_cursor_position(VTE_TERMINAL(display), &column, &row);

 diesen Block rein. Die if-Geschichte

if(column == 0) /* First byte on line */

wird damit ersetzt oder eben ergänzt.

    if(row == 0 && column == 0)
    {                          
      bytes = 0;
      sprintf(data, "%6d: ", total_bytes);
      vte_terminal_feed(VTE_TERMINAL(display), data, strlen(data));
    }

Oder den Daunlohd machen.

Als näxtes kukkich, wie man da Scrollbalken reinkricht
(gtk_scrolled_window_new() sollte es sein).

Statt ellenlangen Beschreibungen, was man alles ändern muß, wäre ein
diff sinnvoller.

Rummaulen kann ich auch! In einem diff steht aber nicht, was da nicht
richtig tikkt. Kann ja sein, daß meine Vorschläge "suboptimal" sind.
Außerdem kenn ich mich mit den Tools so gut auch nicht aus, aber ich
gebe zu, ein diff ist sicherlich sinnvoll, obwohl ja nicht jeder einen
gcc & Co. auf der Platte hat. Da kommt man evtl. mit einem Binärteil
schon besser zurecht. Aber egal, hier ist ein diff aus dem
src/-Verzeichnis. Ich hoffe mal, ich hab das richtig gemacht.

Was ist denn ein diff?

man diff
man patch

auf ner shell oder google fragen

Den Urheber habe ich jetzt zum 2. Mal kontaktiert, auch eine andere
Mail-Adresse, die ich in der Doku gefunden habe, habe ich angeschrieben.
Bisher leider keine Rückmeldung. Ich nehme im übrigen auch an, daß das
Projekt eingeschlafen ist, da seit 2005 keine Updates/Bugfixes mehr
erfolgten.

Gerade eben den Heimatseitenmeister von www.jls-info.com
(jlsinfo,at,wanadoo.fr) angeschrieben, mit der Bitte um Weiterleitung
der angehängten Mail (Fehlerbeschreibung der zwei Bugs). Mal kukken, was
passiert, wenn überhaupt.

Hallo zusammen,

der Bug hat mich gerade nen halben Tag gekostet argh.
Verwende Debian und hab darauf vertraut, dass die Pakete in Ordnung
sind.

Wenn der Urheber des Programms nicht antwortet, koennte man wenigstens
die Paket-Maintainer von Debian dazu bringen, den Bug zu beheben? (Oder
das Paket rausschmeissen ...!)

Kennt jemand das Procedere was man an wen wie schicken soll/darf?

Gruesse

Thorsten