C: time_t zu formatiertem string - Bug?

  • Hi,


    wollte mir für mein Webinterface einen Parser schreiben der die ganzen EPG-Informationen verarbeitet und eine Timeline (html) generiert. Das ganze war mir in PHP aber manchmal viel zu langsam deshalb hab ichs in C geschrieben und habe aber nun ein Problem bei der Konvertierung der Zeit


    Eine printf-Ausgabe (Zeile 98 ) der Variablen die zur Timekonvertierung verwendet werden:
    start: 1296248400, end: 1296255600, sStart: 22:00, sEnd: 22:00


    warum steht in sStart und sEnd das selbe drinnen?
    in tmStart und tmEnd steht auch das gleiche!


    der Code:



    muss allerdings dazu sagen: ich bin kein erfahrener C-Programmierer also kann auch an was ganz simplen liegen...


    thanks and best regards
    aelo

  • Einige Sachen, die mir beim Querlesen aufgefallen sind:


    Zeile 12: Ich würde die Zeiten direkt als int oder time_t oder sowas speichern. Dann kannst du sie später einfacher benutzen.


    Zeile 21: Wenn in dem String kein Leerzeichen vorhanden ist, läuft dein Programm amok. Besser count<length prüfen oder nach '\0' suchen, oder vielleicht gleich strchr verwenden.


    Zeile 27: Eigentlich müsstest du hier noch HTML-Sonderzeichen maskieren.


    Zeile 28: channel wird nicht freigegeben.


    Zeile 30: Vielleicht wäre es einfacher, strptime zu verwenden.


    Zeile 89: Der zweite Aufruf von localtime überschreibt das Ergebnis des ersten Aufrufs. localtime_r hat das Problem nicht.


    Zeile 94: sizeof(sStart) liefert hier die Größe des Zeigers, nicht die des Speichers dahinter. Entweder die 80 direkt einsetzen oder ein richtiges Array verwenden (char sStart[80]). sizeof(char) kannst du dir auch sparen, denn das ist per Definition immer 1.


    Zeile 127: Mit popen kannst du dir die temporäre Datei sparen.


    Zeile 131: Falls dein Compiler getline hat, würde ich das verwenden.


    Zeile 133: Du liest direkt im buffer ohne zu prüfen, ob die Zeile überhaupt so lang ist.


    Mich wundert allerdings, dass es in PHP zu langsam war. Eigentlich macht das Programm nicht viel. War wirklich PHP das Problem oder hat nicht eher die Übertragung der EPG-Daten vom VDR alles aufgehalten?

    Give root password for maintenance (or type Control-D to continue): _

  • Hi,



    vielen Dank da waren wirklcih ein paar geniale Tipps dabei!


    zu den HTML-Sonderzeichen: ist das nicht egal wenn ich beim Ausgaben der HTML-Seite einen ordentlichen UTF-8-Meta Tag mitgebe? zumindest läuft das so ohne Probleme


    beim PHP-Parser dauerte es ewig die Daten zu empfangen vom VDR.
    Habs dann versucht in dem ich es auch in einem file zwischenspeichere aber das parsen dessen File dauerte immer noch ewig, bzw. hörte nie auf


    dachte mir dann ich probiers mal mit C, dann kann ich auch was dazu lernen :D


    mfg
    aelo

  • Zitat

    Originally posted by aelo
    zu den HTML-Sonderzeichen: ist das nicht egal wenn ich beim Ausgaben der HTML-Seite einen ordentlichen UTF-8-Meta Tag mitgebe? zumindest läuft das so ohne Probleme


    Auch bei UTF-8 müssen einige Zeichen (&, <, >, usw.) Maskiert werden. Sonst kann der Browser das nicht mehr eindeutig parsen.


    Weil mit dem Sender namens "I>TELE" kommt dann z.B. sowas dabei raus.

    Code
    <div class="epgchannel">I>TELE</div>

    Das kommt durch keinen HTML Validator.


    Und fehlerhaftes HTML ist einfach schlechter Stil.


    BTW, wenn wir jetzt auch mal ganz pingelig werden wollen ;)
    Es fehlt auch noch die Abfrage nach der Codepage des VDR (die neueren liefern das im SVDRP Replay mit) und die Umwandlung nach UTF-8.


    Und mal grob geraten (habs nicht so mit C), deine Stringverarbeitung erfolgt in 8 Bit, das könnte bei UTF-8 kodierten Strings zu Problemen führen.



    Wobei ich keine Ahnung habe ob bei
    system("sudo svdrpsend LSTE > /tmp/webui_epg.tmp");
    die Konsole noch ne Umwandlung macht. Ich erhalte bei svdrpsend.pl jedenfalls nen Replay mit DOS Linefeeds, keine Ahnung ob bei ner 8-Bit Konsole und nem Unicode VDR noch ne Umwandlung nach 8-Bit stattfindet (d.h. ob die Linux Shell da was wandelt).


    Dieses ganze Geraffel kann ziemlich mühselig werden ;)


    Zitat

    Originally posted by aelo
    aber das parsen dessen File dauerte immer noch ewig, bzw. hörte nie auf


    Klingt nach nem simplen Bug im Code.


    cu

  • Zitat

    Originally posted by Keine_Ahnung
    Und mal grob geraten (habs nicht so mit C), deine Stringverarbeitung erfolgt in 8 Bit, das könnte bei UTF-8 kodierten Strings zu Problemen führen.


    Eigentlich nicht. Das ist ja der große Vorteil von UTF-8, dass man die meisten 8-Bit Stringfunktionen gedankenlos weiter verwenden kann, inklusive Suchfunktionen und Sortierfunktionen. Der einzig wesentliche Unterschied zu 8-Bit Zeichensätzen ist der Unterschied Anzahl Zeichen != Anzahl Bytes.


    Zitat

    system("sudo svdrpsend LSTE > /tmp/webui_epg.tmp");


    Brrrr, was macht denn das sudo da???
    svdrpsend baut doch nur eine Netzwerkverbindung auf, dafür braucht es ziemlich sicher keine root-Rechte.


    Gruß,


    Udo

  • Zitat

    Originally posted by Urig


    Eigentlich nicht. Das ist ja der große Vorteil von UTF-8, dass man die meisten 8-Bit Stringfunktionen gedankenlos weiter verwenden kann, inklusive Suchfunktionen und Sortierfunktionen. Der einzig wesentliche Unterschied zu 8-Bit Zeichensätzen ist der Unterschied Anzahl Zeichen != Anzahl Bytes.


    Meine Idee ging in die Richtung das, wenn man nach nem Zeichen >127 Sucht, es durchaus sein kann das eines der Folgebytes einer UTF-8 Sequenz zufällig den selben ASCI II Wert haben könnte.


    OK, hab mal gerade bei Wikipedia nach UTF-8 Nachgeschlagen, ist in diesem Fall anscheinend wirklich kein Problem.


    BTW: Aber die Sortierfunktionen sollten so keinen Spaß machen, jedenfalls nicht wenn man mit Umlauten spielt ;)


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!