yavdr vdr-2.5.4-patch-for-permashift.diff compiler warning

  • Nachdem ich wegen dem Timeout Thema oft den VDR kompiliert hatte, ist mir eine warning bei yavdr aufgefallen.

    Der o.g. Patch erzeugt folgende Compiler Warnung:

    Hier ein Fix dazu:

    VDR
  • Ich verstehe die Warnung nicht.

    So ging es mir auch. Ich wollte trotzdem die unwichtige warning los haben, damit man die wichtigen Meldungen besser sehen kann.

    VDR
  • Ich habe es gestern Abend in die Pakete für den VDR 2.6.1 eingebaut.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Deswegen..


    Im constructor werden die privaten Variablen durch den Patch in unsortierter Reihenfolge initialisiert.


    Besser:

    Diff
    1. diff --git a/recorder.c b/recorder.c
    2. index 47dd6a5b..79408272 100644
    3. --- a/recorder.c
    4. +++ b/recorder.c
    5. @@ -164,11 +164,25 @@ void cFrameChecker::ReportBroken(void)
    6. cRecorder::cRecorder(const char *FileName, const cChannel *Channel, int Priority)
    7. :cReceiver(Channel, Priority)
    8. ,cThread("recording")
    9. +,tsChecker(NULL), frameChecker(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), recordingInfo(NULL), index(NULL), recordFile(NULL), recordingName(NULL)
  • Das verstehe ich natürlich und ich würde die Änderung auch übernehmen, wenn ich nachvollziehen könnte, warum die Warnung kommt ;-).

    Das ist vielleicht ein Missverständnis. Diese Warnung kommt nicht beim Core-VDR, sondern durch den patch-for-permashift.

    Das Problem ist, das der Kompiler hier scheinbar erwartet, das bestimmte Dinge in der gleichen Reihenfolge aufgerufen werden.

    Wenn man also recorder.h so lässt, wie es war und dafür recorder.c entsprechend ändert, ist die Warnung auch weg:

    Code
    1. im Constructor cRecorder::cRecorder:
    2. aus:
    3. ,tsChecker(NULL), frameChecker(NULL), recordingInfo(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), index(NULL), recordFile(NULL), recordingName(NULL)
    4. das:
    5. ,tsChecker(NULL), frameChecker(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), recordingInfo(NULL), index(NULL), recordFile(NULL), recordingName(NULL)

    Diese Warnung hatte ich damals beim korrigieren des Patches übersehen.

    Im Prinzip könnte man auch mal einen neuen Patch für vdr-2.6.x machen...


    Grüße

    kamel5


    PS: wirbel war schneller

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Diese Warnung kommt nicht beim Core-VDR, sondern durch den patch-for-permashift.

    Ja genau,

    kls : Du brauchst hier nichts ändern, im ungepatchen VDR kommt die Warnung nicht.


    Wenn man also recorder.h so lässt, wie es war und dafür recorder.c entsprechend ändert, ist die Warnung auch weg:

    Stimmt, das wäre besser, weil näher am original VDR dran.

    VDR

    The post was edited 1 time, last by kfb77 ().

  • Ich denke, die durch den Patch hinzugefügte Initialisierung der private members wäre auch im ungepatchten VDR gut.

  • +,tsChecker(NULL), frameChecker(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), recordingInfo(NULL), index(NULL), recordFile(NULL), recordingName(NULL)

    Wozu soll das gut sein, ausser dass es die Übersichtlichkeit stört?

    Warum hat der Patch das überhaupt eingeführt?

    Wäre die Warnung weg, wenn man diese Änderung im Patch ganz entfernen würde?

  • Na ja, Variablen in einer Klasse können schon gut eine Initialisierung gebrauchen,

    da man ohne leicht den Überblick verliert.


    Aber die Frage geht sicher eher an den Ersteller des Patches.

  • Wozu soll das gut sein, ausser dass es die Übersichtlichkeit stört?

    Warum hat der Patch das überhaupt eingeführt?

    Wäre die Warnung weg, wenn man diese Änderung im Patch ganz entfernen würde?

    Ich finde initialisierte Daten immer besser als zufällige. Im Zweifel sorgt es für besser verstehbare Fehler, wenn NULL verwendet wird und nicht irgendein 0x0815.


    Aber falls du dich dafür interessieren solltest, den Permashift-Patch in den Core-VDR aufzunehmen, wär' ich total kompromissbereit... ;)
    Ich denke, er hat bewiesen, dass er langlebig ist.