Compiler warning

RHS · Mar 25th 2019

Beim Übersetzen von VDR mit allen Patches (1-26) und folgendem Compiler

Code

gcc (SUSE Linux) 8.3.1 20190226 [gcc-8-branch revision 269204]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

erhalte ich folgende Warnung:

Code

g++ -g -O3 -Wall -march=native -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/srv/vdr/video\" -DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/local/share/vdr\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/uuid -I/usr/include/freetype2  -o dvbplayer.o dvbplayer.c

ci.c: In member function 'bool cCiMMI::SendAnswer(const char*)':

ci.c:1585:13: warning: 'char* strncpy(char*, const char*, size_t)' specified bound 256 equals destination size [-Wstringop-truncation]

      strncpy(answer.text, Text, sizeof(answer.text));

      ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CC dvbspu.o

und Später:

g++ -g -O3 -Wall -march=native -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/srv/vdr/video\" -DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/local/share/vdr\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/uuid -I/usr/include/freetype2  -o remux.o remux.c
recording.c: In member function 'void cIndexFile::ConvertToPes(tIndexTs*, int)':
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));
                                                    ^
recording.c:2502:8: note: 'struct tIndexTs' declared here
 struct tIndexTs {
        ^~~~~~~~
CC ringbuffer.o
g++ -g -O3 -Wall -march=native -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/srv/vdr/video\" -DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/local/share/vdr\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/uuid -I/usr/include/freetype2  -o ringbuffer.o ringbuffer.c
recording.c: In function 'char* ExchangeChars(char*, bool)':
recording.c:607:37: warning: 'char* strncpy(char*, const char*, size_t)' output may be truncated copying 3 bytes from a string of length 3 [-Wstringop-truncation]
                              strncpy(p, buf, 3);
                              ~~~~~~~^~~~~~~~~~~
CC sdt.o

Display More

VDR compiliert durch und läuft auch soweit. Gelegentlich gibt es aber beim umschalten von Kanälen und gleichzeitigen laufenden Aufnahmen Speicherzugriffsfehler

folgender Art:

Code

Mär 24 22:45:56 vnas2 kernel: traps: general protection fault ip:7fd745e3fea6 sp:7fd6b17f9a70 error:0 in libc-2.29.so[7fd745ddc000+14c000]

Können diese Warnungen etwas mit den general Protection fault zu tun haben?

Wenn nicht, ist es möglich diese Warnungen in Hinblick auf 2.4.1 zu fixen?

Beste Grüße

wirbel · Mar 25th 2019

recording.c:604

Code

char buf[4];
sprintf(buf, "#%02X", (unsigned char)*p);
memmove(p + 2, p, strlen(p) + 1);
strncpy(p, buf, 3);
p += 2;

in buf wird ein c string aus einer Raute '#', zwei Zeichen der hex-Zahl sowie eine nachfolgende Null abgelegt;

strncpy kopiert drei bytes maximal, da passt die Null nicht mehr rein. Der compiler warnt hier zu Recht, dass kein nulltermierter c-String in p stehen wird.

auch das Increment von p sieht um ein byte oder zwei byte zu klein aus - ansonsten hätte man nicht vorher "#%02X" nutzen sollen.

wirbel · Mar 25th 2019

..möglicherweise war ursprünglich gemeint

char buf[4];

sprintf(buf, "#%02X", (unsigned char)*p);

memmove(p + 2, p, strlen(p) + 1);

strncpy(p, buf, 4);

p += 3;

RHS · Mar 25th 2019

Danke für die schnelle Analyse.

hab mal einen Patch gebaut.

Diff

--- recording.c.orig    2019-03-23 18:00:06.497575008 +0100
+++ recording.c 2019-03-25 15:10:39.980656935 +0100
@@ -604,8 +604,8 @@ char *ExchangeChars(char *s, bool ToFile
                              char buf[4];
                              sprintf(buf, "#%02X", (unsigned char)*p);
                              memmove(p + 2, p, strlen(p) + 1);
-                             strncpy(p, buf, 3);
-                             p += 2;
+                             strncpy(p, buf, 4);
+                             p += 3;
                              }
                           else

Display More

M-Reimer · Mar 25th 2019

Sind die anderen Warnings auch davon?

Hoffentlich bekommt Klaus von dem Thread mit.

Stoff für das Flickwerk *hust* Patchsammlung.

RHS · Mar 25th 2019

Nein. Dies betrifft nur die 3.Warnung.

kls · Mar 25th 2019

Hab's gesehen

wirbel · Mar 25th 2019

Die erste Warnung des compilers in ci.c:1577 hat auch so seine Berechtigung.

'Text' kann länger als 256 Zeichen sein und struct answer könnte je nach compiler aligned sein,

u.U. auch strlen(answer.text) != strlen(Text) in SendData.

Code

bool cCiMMI::SendAnswer(const char *Text)
{
dbgprotocol("Slot %d: ==> Answ (%d)\n", CamSlot()->SlotNumber(), SessionId());
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);
return true;
}

Display More

M-Reimer · Mar 25th 2019

Hier rächt es sich in gewissem Maß, dass der VDR eine "Mischung" aus C++ und C ist.

Klar, der Compiler macht in gewissem Maß ein Audit und findet solche Fehler, aber mein Informatik-Dozent hat nicht nur einmal betont, dass man in C++ immer die stdlib nutzen soll und das C-Strings böse sind. Mit C++-Strings wäre das nicht passiert

mini73 · Mar 25th 2019

Wenn man immer so programmieren würde, wie Dozenten das verlangen, käme man nie zu einem Ergebnis...

HelmutB · Mar 25th 2019

Zur 3. Warnung:

Ich glaube es sollte genügen die Zeile 607 in recording.c inmemcpy(p, buf, 3); zu ändern.

Hier wird ein Zeichen durch einen 3 Byte Hexcode ersetzt - deshalb zuerst die Verschiebung des String um 2 Bytes nach hinten um Platz zu schaffen. Das '0'-Byte des Ersatzstring darf nicht mitkopiert werden, ein strncpy(p, buf, 4); wie im Patch schneidet den String gleich nach der ersten Ersetzung ab.

Helmut

RHS · Mar 27th 2019

Der Vorschlag in #11 eliminiert ebenfalls die Compiler Warnung.

Im folgenden, ein Patch hierzu:

Diff

--- recording.c.orig    2019-03-23 18:00:06.497575008 +0100
+++ recording.c 2019-03-27 10:43:37.316241999 +0100
@@ -604,7 +604,7 @@ char *ExchangeChars(char *s, bool ToFile
                              char buf[4];
                              sprintf(buf, "#%02X", (unsigned char)*p);
                              memmove(p + 2, p, strlen(p) + 1);
-                             strncpy(p, buf, 3);
+                             memcpy(p, buf, 3);
                              p += 2;
                              }
                           else

Display More

HelmutB · Mar 27th 2019

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.

Die beiden strncpy() Aufrufe sind keine Fehler, memcpy(IndexTs, &IndexPes, sizeof(*IndexTs));in recording.c, Zeile 2637 allerdings schon;

Die Länge von struct tIndexPes (64 Bit) ist kleiner als die der struct tIndexTs es soll aber nur der Inhalt von IndexPes in die ersten 64 Bit von IndexTS kopiert werden. Also müsste hier memcpy(IndexTs, &IndexPes, sizeof(*IndexPes)); stehen.

Das kann - oder besser - wird die Ursache für den Speicherzugriffsfehler sein.

Helmut

Edit: ich sehe gerade das die Funktion ConvertToPes mit obigen Fehler eben nur bei Pes-Aufnahmen verwendet wird - das sind Aufnahmen mit der Endung ".vdr" ->

bool IsPesRecording = fileName && endswith(fileName, ".vdr");

Da das bei die eher nicht der Fall sein wird (oder?), kann der Speicherzufriffsfehler aber auch eine andere Ursache haben

RHS · Mar 27th 2019

Danke

hier ein Patch zum Fix ci.c:

Diff

--- ci.c.orig   2019-03-23 18:00:23.557474204 +0100
+++ ci.c        2019-03-27 13:09:14.360380770 +0100
@@ -1582,7 +1582,7 @@ bool cCiMMI::SendAnswer(const char *Text
   tAnswer answer;
   answer.id = Text ? AI_ANSWER : AI_CANCEL;
   if (Text)
-     strncpy(answer.text, Text, sizeof(answer.text));
+     memcpy(answer.text, Text, sizeof(answer.text));
   SendData(AOT_ANSW, Text ? strlen(Text) + 1 : 1, (uint8_t *)&answer);
   return true;
 }

Display More

Meine Aufnahmen sind .ts files.

Beim compilieren erhalte ich mit o.g. Fix für recording.c zeile 2637 folgende Fehlermeldung:

Code

CC recording.o
g++ -g -O3 -Wall -march=native -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/srv/vdr/video\" -DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/local/share/vdr\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/uuid -I/usr/include/freetype2  -o recording.o recording.c
recording.c: In member function 'void cIndexFile::ConvertToPes(tIndexTs*, int)':
recording.c:2637:43: error: no match for 'operator*' (operand type is 'tIndexPes')
         memcpy(IndexTs, &IndexPes, sizeof(*IndexPes));
                                           ^~~~~~~~~

HelmutB · Mar 27th 2019

Hab ich übersehen - IndexPes ist ja kein Pointer sondern die struct selbst, also nun ohne "*" -> memcpy(IndexTs, &IndexPes, sizeof(IndexPes));.

Helmut

Kleine Ergänzung: damit soll eigentlich nur der Fehler behoben werden, die Warnung wird vermutlich bleiben.

Ich kann es jetzt nicht ausprobieren, aber vieleicht braucht es dafür noch &IndexTS->offsetals erstes Argument.

RHS · Mar 27th 2019

Ohne Stern gibt es keinen Error sondern folgende Warnung:

Code

g++ -g -O3 -Wall -march=native -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/srv/vdr/video\" -DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/local/share/vdr\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/share/locale\" -I/usr/include/uuid -I/usr/include/freetype2  -o recording.o recording.c
recording.c: In member function 'void cIndexFile::ConvertToPes(tIndexTs*, int)':
recording.c:2637:45: 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(IndexPes));
                                             ^
recording.c:2502:8: note: 'struct tIndexTs' declared here
 struct tIndexTs {
        ^~~~~~~~
CC thread.o

HelmutB · Mar 27th 2019

Das mit der Warnung habe ich erwartet.

In der Eränzung von meinem letzten Post hätte ich mir die Zeile so vorgstellt: memcpy(&IndexTs->offset, &IndexPes, sizeof(IndexPes)); - vielleicht lässt es gcc dann als "trivial" durchgehen obwohl es nach dem Datentype eigentlich mmer noch nicht richtig passt.

Ich werde es am Abend ausprobieren.

Helmut

HelmutB · Mar 27th 2019

Bei &IndexTs->offsetgibt es einen Fehler wegen dem Pointer ein bit-field.

Aber so bemängelt gcc-8.2.0 in recording.c nichts mehr:

Diff

--- recording.c.orig    2018-03-17 11:56:13.000000000 +0100
+++ recording.c    2019-03-27 19:50:48.926806610 +0100
@@ -2634,7 +2634,7 @@ void cIndexFile::ConvertToPes(tIndexTs *
         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((char *)IndexTs, &IndexPes, sizeof(IndexPes));
         IndexTs++;
         }
 }

Display More

Helmut

RHS · Mar 28th 2019

Danke für die Unterstützung.

Nun compiliert vdr mit dem o,g, compiler ohne Warnungen.

seahawk1986 · Apr 5th 2019

Könntet ihr eventuell einen Patch mit allen nötigen Änderungen posten?

Compiler warning

Participate now!

Share