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

Ich verstehe die Warnung nicht. Beides sind Pointer, die nicht voneinander anghängen. Welche Rolle spielt es, in welcher Reihenfolge sie definiert sind? Übersehe ich da was?

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

Quote from kfb77

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

Das verstehe ich natürlich und ich würde die Änderung auch übernehmen, wenn ich nachvollziehen könnte, warum die Warnung kommt ;-).

Deswegen..

recorder.h:22ff

class cRecorder : public cReceiver, cThread {
private:
  cTsChecker *tsChecker;
  cFrameChecker *frameChecker;
  cRingBufferLinear *ringBuffer;
  cFrameDetector *frameDetector;
  cPatPmtGenerator patPmtGenerator;
  cFileName *fileName;
  cRecordingInfo *recordingInfo;
  cIndexFile *index;
  cUnbufferedFile *recordFile;
  char *recordingName;
  bool firstIframeSeen;
  off_t fileSize;
  time_t lastDiskSpaceCheck;
  time_t lastErrorLog;
  int oldErrors;
  int errors;
  int lastErrors;
  bool RunningLowOnDiskSpace(void);
  bool NextFile(void);
  void HandleErrors(bool Force = false);


diff --git a/recorder.c b/recorder.c
index 47dd6a5b..79408272 100644
--- a/recorder.c
+++ b/recorder.c
@@ -164,11 +164,25 @@ void cFrameChecker::ReportBroken(void)
 cRecorder::cRecorder(const char *FileName, const cChannel *Channel, int Priority)
 :cReceiver(Channel, Priority)
 ,cThread("recording")
+,tsChecker(NULL), frameChecker(NULL), recordingInfo(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), index(NULL), recordFile(NULL), recordingName(NULL)

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

Besser:

diff --git a/recorder.c b/recorder.c
index 47dd6a5b..79408272 100644
--- a/recorder.c
+++ b/recorder.c
@@ -164,11 +164,25 @@ void cFrameChecker::ReportBroken(void)
 cRecorder::cRecorder(const char *FileName, const cChannel *Channel, int Priority)
 :cReceiver(Channel, Priority)
 ,cThread("recording")
+,tsChecker(NULL), frameChecker(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), recordingInfo(NULL), index(NULL), recordFile(NULL), recordingName(NULL)

Quote from kls

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:

im Constructor cRecorder::cRecorder:
aus:
,tsChecker(NULL), frameChecker(NULL), recordingInfo(NULL), ringBuffer(NULL), frameDetector(NULL), fileName(NULL), index(NULL), recordFile(NULL), recordingName(NULL)
das:
,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

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

Quote from wirbel

+,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.

Das wäre dann Ein Eike .

Grüße

kamel5

Quote from kls

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.