Uninitialised value wurde durch einen heap-Zuweisung

Habe ich schon jagen, dieser bug herum, und ich verstehe es einfach nicht. Habe ich vergessen einige grundlegende C oder so etwas?

==28357== Conditional jump or move depends on uninitialised value(s)
==28357==    at 0x4C261E8: strlen (mc_replace_strmem.c:275)
==28357==    by 0x4E9280A: puts (ioputs.c:36)
==28357==    by 0x400C21: handlePath (myshell.c:105)
==28357==    by 0x400B17: handleInput (myshell.c:69)
==28357==    by 0x400AAD: acceptInput (myshell.c:60)
==28357==    by 0x4009CF: main (myshell.c:33)
==28357==  Uninitialised value was created by a heap allocation
==28357==    at 0x4C25153: malloc (vg_replace_malloc.c:195)
==28357==    by 0x400BDE: handlePath (myshell.c:99)
==28357==    by 0x400B17: handleInput (myshell.c:69)
==28357==    by 0x400AAD: acceptInput (myshell.c:60)
==28357==    by 0x4009CF: main (myshell.c:33)
==28357==

(095) void handlePath(char *input) {
(096)     if(DEBUG_ON) { printf("%s%s\n", "DEBUG_HANDLEPATH: ", input); }
(097)
(098)     char *inputCopy = NULL;
(099)     inputCopy = (char *)malloc((strlen(input)+1)*sizeof(char));
(100)
(101)     if(inputCopy==NULL) {
(102)         die("malloc() failed in handlePath()");
(103)     }
(104)     strncpy(inputCopy, input, strlen(input)*sizeof(char));
(105)     printf("%s\n", inputCopy);
(106)     free(inputCopy);
(107)     return;
(108) }

Linie 96 druckt die parameter "char *input" just fine (DEBUG_ON==1), aber die Linie 105 spuckt valgrind-Fehler (nicht drucken, nur feiner in der Konsole). "char *input" stammt aus einer getline (), der nach einer Zeile, und in dieser Funktion so etwas wie "Pfad /test/path" ohne Anführungszeichen. Ich kann drucken und Bearbeiten es ganz gut in vorangegangenen Funktionen. Was nicht initialisierte über "char *inputCopy"? Irgendwelche Ideen? Vielen Dank im Voraus!

InformationsquelleAutor der Frage yavoh | 2010-01-30

  1. 13

    Haben Sie zwei Fehler in Zeile 104,

    strncpy(inputCopy, input, strlen(input)*sizeof(char));

    Müssen Sie zu geben, strncpy Platz für das abschließende Nullzeichen, so sollte es sein strlen(input)+1
    strncpy ist nicht garantiert, verlassen Sie die Ausgabe-Puffer-null beendet, was scheint wie ein bug in strncpy ist es aber nicht. Es wurde entworfen, um zu arbeiten, Weg. Was strncpy wurde entworfen, um zu tun war, kopieren Sie eine Zeichenfolge in einen Ausgabe-Puffer und dann füllen Sie den rest der Puffer mit Nullen., Es ist nicht wirklich entwickelt, als eine "sichere strcpy'

    Ihre andere Fehler ist, dass strncpy dauert Charakter zählen nicht die Anzahl Bytes, also ist es falsch zu multiplizieren, indem sizeof(char).. Da sizeof(char) == 1, dann ist dies nicht wirklich Probleme verursacht, aber seine immer noch die falsche Absicht.

    Waren Sie richtig durch multiplizieren sizeof(char) im malloc on line 99 seit malloc muss eine byte-Anzahl.

    InformationsquelleAutor der Antwort John Knoeller

  2. 4

    strncpy nicht ein abschließendes 0-Zeichen, wie es kopiert höchstens N Zeichen (wo N ist die 3-parameter). Da Sie angegeben haben, die Länge und nicht das +1 für die abschließende 0, es wurde nicht Hinzugefügt.

    Vorausgesetzt, Sie haben einen Puffer von N bytes, die die ordnungsgemäße Verwendung von strncpy, ist dies:

    strncpy(dest, src, N - 1);
dest[N - 1] = '\0';

    strncpy ist eine seltsame Funktion. Neben nicht verspricht, schreiben Sie eine terminierende 0, es wird immer genau schreiben N-Zeichen in den Zielpuffer. Wenn src kleiner als N, strncpy tatsächlich die Zeit nehmen, die füllen den gesamten rest des Puffers mit 0.

    InformationsquelleAutor der Antwort R Samuel Klatchko

  3. 3

    Glaube ich nicht, dass strncpy ist nicht putting ein abschließendes null-Zeichen am Ende der Zeichenfolge, sodass printf () ausgeführt wird, über das Ende des allozierten Speicher.

    InformationsquelleAutor der Antwort Mark Ransom

Schreibe einen Kommentar