Compiler warning

Falls RHS ihn nicht schon vorher postet kann ich es morgen Nachmittag tun.

Helmut

Danke, damit ist klar, was rein muss und was nicht.

Zitat von HelmutB

RHS : Wenn du in ci.c, Zeile 1584 strncpy ebenfalls durch memcpy sollte diese Warnung auch nicht mehr auftauchen. Hier soll kein "C"-String in den Buffer geschrieben werden.

Damit werden aber immer 256 Byte kopiert, auch wenn Text nur sehr kurz ist. Wobei das freilich kein Fehler wäre, aber unnötig.

Während der Tausch von strncpy() gegen memcpy() lediglich den Compiler zufriedenstellt, aber keinen Fehler behebt, lauert da aber immer noch ein Problem, wenn Text länger als 256 Byte sein sollte. Dann würde nämlich bei SendData() eine zu große zu kopierende Puffergröße angegeben. Daher schlage ich folgenden Patch vor:

--- ci.c        2019/05/05 14:15:56     5.3
+++ ci.c        2019/05/06 11:47:42
@@ -1591,9 +1591,12 @@
   struct tAnswer { uint8_t id; char text[256]; };//XXX
   tAnswer answer;
   answer.id = Text ? AI_ANSWER : AI_CANCEL;
-  if (Text)
-     strncpy(answer.text, Text, sizeof(answer.text));
-  SendData(AOT_ANSW, Text ? strlen(Text) + 1 : 1, (uint8_t *)&answer);
+  int len = 0;
+  if (Text) {
+     len = min(sizeof(answer.text), strlen(Text));
+     memcpy(answer.text, Text, len);
+     }
+  SendData(AOT_ANSW, len + 1, (uint8_t *)&answer);
   return true;
 }

Zitat von HelmutB

Die Länge von struct tIndexPes (64 Bit) ist kleiner als die der struct tIndexTs

Nein, beide sind exakt gleich groß, nämlich 64 Bit.

Zitat von RHS

recording.c:2637:52: warning: 'void* memcpy(void*, const void*, size_t)' copying an object of non-trivial type 'struct tIndexTs' from an array of 'struct tIndexPes' [-Wclass-memaccess]
memcpy(IndexTs, &IndexPes, sizeof(*IndexTs));

Hier nimmt es der Compiler wohl etwas sehr genau, weil tIndexTs einen Konstruktor hat.

Na gut, soll er. Aber wenn schon, dann würde ich nach (void *) casten:

--- recording.c 2019/05/06 11:26:06     5.3
+++ recording.c 2019/05/06 12:37:13
@@ -2640,7 +2640,7 @@
         IndexPes.type = uchar(IndexTs->independent ? 1 : 2); // I_FRAME : "not I_FRAME" (exact frame type doesn't matter)
         IndexPes.number = uchar(IndexTs->number);
         IndexPes.reserved = 0;
-        memcpy(IndexTs, &IndexPes, sizeof(*IndexTs));
+        memcpy((void *)IndexTs, &IndexPes, sizeof(*IndexTs));
         IndexTs++;
         }
 }

RHS: kannst du bitte verifizieren, ob dieser Patch das Problem auch behebt?

Zitat von kls

Nein, beide sind exakt gleich groß, nämlich 64 Bit.

Richtig. Ich habe übersehen, das hier Bitfelder definiert werden - die genutzen Bits sind in beiden Fällen 64 Bit.

Sofern die Bitfelder und die andere Elemente vom Compiler ohne Füllbytes zusammengefügt ist die Größe ident.

Aber sollte hier nicht zur Sicherheit ein __attribute__ ((__packed__)) oder ähnliches angewendet werden?

Helmut

Man würde damit sicher nichts verkehrt machen ;-).

Da hat er recht.

Es muss heissen:

esyslog("ERROR: can't copy file name '%s'", FileName);

(fileName -> FileName)

Wobei, wenn er an diese Stelle kommt, ist eh alles aus... ;-).