Ich würde den Parameter weiterhin bei 1 beginnen lassen, damit die Nummerierung mit der Ausgabe von man epgsearch.conf zusammenpasst.
Gut, dann lassen wir das so. Andernfalls hätte ich man epgsearch.conf halt entsprechend angepasst.
Gibt es einen Grund, dass das Zurückschreiben von leeren Feldern (::) den alten Wert bestehen lassen soll oder war das ein Bug?
Der derzeitige Codes führt genau zu diesem Verhalten:
while (*pos) {
while (*pos == ' ') pos++;
if (*pos) {
if (*pos != ':') {
...
pos = pos_next;
switch (parameter) {
case 1:
...
default:
break;
} //switch
}
parameter++;
}
if (*pos) pos++;
} //while
Display More
Wenn nach einem Doppelpunkt unmittelbar ein weiterer folgt (führende Spaces werden in Zeile 2 übersprungen), dann wird switch nicht durchlaufen und das entsprechende Attribute nicht somit auch nicht modifiziert. Insofern würde ich dies eher als – durchaus nützliches – Feature betrachten. Ein paar Kommentare in diese Richtung gab es weiter oben ja schon.
In welchem Zusammenhang kommt ... vor?
Das war nur aus editorischen Gründen, damit ich nicht den ganzen Kram davor in den Post kopieren musste.
Noch ein paar ergänzende Infos… Die Arbeiten am Code fallen wohl doch etwas umfangreicher aus:
- Ich habe auf Anregungen von SHF schon mal alle Patterns der Form if (p) free(p); auf free(p); reduziert, weil free(NULL); zulässig ist und intern das gleiche macht. Damit wird der Code leichter lesbar.
- Die diversen strreplace-Funtionen habe ich etwas gehärtet, damit bspw. bei einem leeren Suchstring keine Endlosschleife entsteht. Klaus zieht das im VDR ebenfalls nach.
- Ein paar Memory Leaks, die mir aufgefallen sind, habe ich ebenfalls bereinigt.
- Die Parser habe ich mit Checks ausgestattet, die bei Parse-Fehlern oder unzulässigen Parameterwerten einen aussagekräftigen Syslog-Eintrag erzeugen. Ob man nach einem Validierungsfehler weitere Parameter einlesen möchte, lässt sich per Flag steuern (default: wie bisher). Die Idee ist, beim Laden der Konfiguration fehlertolerant zu sein, damit EPGsearch so gut wie möglich losläuft, beim SVDRP-Interface und API (also beim Neuanlegen und Bearbeiten von Objekten) aber streng, damit keine fehlerhaften Daten in die Datenbasis einfließen.
- Die etwas unübersichtlichen Schleifen der Form cSearchExtCat *SearchExtCat = SearchExtCats.First();int index = 0; while (SearchExtCat) { ...; SearchExtCat = SearchExtCats.Next(SearchExtCat); index++; } habe ich dort, wo SearchExtCat im Schleifenrumpf nicht für andere Objektzugriffe genutzt wird – also insbesondere bei der Verwaltung der catvalues – auf for (int index = 0; index < SearchExtCats.Count(); index++) { ... } reduziert. Weil etwa die catvalues auch anhand von SearchExtCats.Count() dimensioniert werden, ist das nicht nur schlüssiger, sondern zudem auch lesbarer.
- Die Puffer fester Größe sind ein echtes Problem. Beispielsweise fassen sie nicht einmal alle Genres aus dem EPG-Sample:
[BASH] s="Abenteuer,Action,Boxen,Comedy,Dokumentarfilm,Drama,Erotik,Familien-Show,Fantasy,Fussball,Geschichte,Gesellschaft,Gesundheit,Gymnastik,Handball,Heimat,Humor,Jazz,Kinderfilme,Kindernachrichten,Kinderserien,Klassik,Krankenhaus,Krimi,Kultur,Kurzfilm,Motor+Verkehr,Motorsport,Musik,Mystery,Nachrichten,Natur,Politik,Radsport,Ratgeber,Reise,Rock,Romantik/Liebe,Science Fiction,Soap,Spielshows,Talkshows,Tennis,Thriller,Verschiedenes,Volksmusik,Wassersport,Western,Wintersport,Wirtschaft,Wissen,Zeichentrick"
[BASH] echo ${#s}
500
[BASH] printf "%.*s" 254 "$s"
Abenteuer,Action,Boxen,Comedy,Dokumentarfilm,Drama,Erotik,Familien-Show,Fantasy,Fussball,Geschichte,Gesellschaft,Gesundheit,Gymnastik,Handball,Heimat,Humor,Jazz,Kinderfilme,Kindernachrichten,Kinderserien,Klassik,Krankenhaus,Krimi,Kultur,Kurzfilm,Motor+Ve
Und wenn man im OSD alle diese Einträge aktiviert, stürzt der VDR noch im OSD ab. Ich beabsichtige deshalb, die ganzen Puffer fester Größe zu eliminieren und mich eher an cReadLine des VDR zu orientieren, sprich: getline() mit dynamisch allokiertem Puffer zu nutzen und auch in den Objekten char value[MaxFilename] durch char* value usw. zu ersetzen. Oder doch gleich besser std::string? - Alle Aufrufe von strdup() usw. sollte man auf Fehlerzustände (NULL-Pointer) prüfen und eine sinnvolle Fehlerbehandlung vorsehen. Das wäre aber wohl eher ein getrennter Schritt, sprich: Pull-Request.
- Auch sollte man die bislang öffentlichen Klassen-Attribute verbergen und den Zugriff – wie etwa im VDR – ausschließlich über Getter und Setter zulassen. Dann wäre es auch egal, ob String-Attribute intern als char[], char* oder std::string repräsentiert würden. Ebenfalls etwas für die To-Do-Liste.
Etliche Tage an intensiver Arbeit sind da schon reingeflossen. Man stolpert von einem unschönen Effekt zum Nächsten, deshalb auch die inzwischen schon etwas umfangreiche Liste von oben. Ein gründlicher Review samt Testphase sind dann unbedingt notwendig.
Aber wenn dir das alles nicht recht ist, wäre es fair, das gleich zu sagen, bevor ich noch mehr Zeit investiere und du den Pull-Request am Schluss doch nicht nimmst.
Und eigentlich wollte ich für Suchtimer ja nur ein weiteres Feld für Notizen haben…