Ist es garantiert sicher, memcpy (0,0,0) auszuführen?

Ich bin nicht so gut mit dem C-Standard vertraut, bitte nehmen Sie Kontakt mit mir auf.

Ich würde gerne wissen, ob es standardmäßig garantiert ist, dass memcpy(0,0,0)es sicher ist.

Die einzige Einschränkung, die ich finden konnte, ist, dass das Verhalten undefiniert ist, wenn sich die Speicherbereiche überlappen ...

Aber können wir berücksichtigen, dass sich die Speicherbereiche hier überlappen?

Ich habe eine Entwurfsversion der C-Norm (ISO / IEC 9899: 1999), und es gibt einige lustige Dinge zu diesem Aufruf zu sagen. Für den Anfang erwähnt sie (§7.21.1 / 2) in Bezug auf memcpydas

Wenn ein als size_tn deklariertes Argument die Länge des Arrays für eine Funktion angibt, kann n bei einem Aufruf dieser Funktion den Wert Null haben. Sofern in der Beschreibung einer bestimmten Funktion in diesem Unterabschnitt nicht ausdrücklich anders angegeben, müssen Zeigerargumente für einen solchen Aufruf weiterhin gültige Werte haben, wie in 7.1.4 beschrieben . Bei einem solchen Aufruf findet eine Funktion, die ein Zeichen findet, kein Vorkommen, eine Funktion, die zwei Zeichenfolgen vergleicht, gibt Null zurück, und eine Funktion, die Zeichen kopiert, kopiert Null Zeichen.

Die hier angegebene Referenz weist darauf hin:

Wenn ein Argument für eine Funktion einen ungültigen Wert hat (z. B. einen Wert außerhalb des Funktionsbereichs oder einen Zeiger außerhalb des Adressraums des Programms oder einen Nullzeiger oder einen Zeiger auf einen nicht veränderbaren Speicher, wenn der entsprechende Parameter vorhanden ist ist nicht const-qualifiziert) oder ein Typ (nach der Heraufstufung), der von einer Funktion mit variabler Anzahl von Argumenten nicht erwartet wird, ist das Verhalten undefiniert .

Es sieht also so aus, als würde man gemäß der C-Spezifikation anrufen

memcpy(0, 0, 0)

führt zu undefiniertem Verhalten, da Nullzeiger als "ungültige Werte" betrachtet werden.

Trotzdem wäre ich äußerst erstaunt, wenn eine tatsächliche Implementierung von memcpypleite wäre, wenn Sie dies tun würden, da die meisten intuitiven Implementierungen, die mir einfallen, überhaupt nichts bewirken würden, wenn Sie sagen würden, dass sie null Bytes kopieren sollen.

Nur zum Spaß zeigen die Versionshinweise für gcc-4.9 an, dass sein Optimierer diese Regeln verwendet und beispielsweise die Bedingung in entfernen kann

int copy (int* dest, int* src, size_t nbytes) {
    memmove (dest, src, nbytes);
    if (src != NULL)
        return *src;
    return 0;
}

Dies führt dann zu unerwarteten Ergebnissen, wenn copy(0,0,0)es aufgerufen wird (siehe https://gcc.gnu.org/gcc-4.9/porting_to.html ).

Ich bin etwas ambivalent in Bezug auf das Verhalten von gcc-4.9; Das Verhalten ist möglicherweise standardkonform, aber das Aufrufen von memmove (0,0,0) ist manchmal eine nützliche Erweiterung dieser Standards.

Sie können diese Verwendung memmoveauch in Git 2.14.x (Q3 2017) berücksichtigen.

Siehe Commit 168e635 (16. Juli 2017) und Commit 1773664 , Commit f331ab9 , Commit 5783980 (15. Juli 2017) von René Scharfe ( rscharfe) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 32f9025 , 11. August 2017)}

Es verwendet ein Hilfsmakro,MOVE_ARRAY das die Größe basierend auf der für uns angegebenen Anzahl von Elementen berechnet und NULL Zeiger unterstützt, wenn diese Anzahl Null ist.
Rohe memmove(3)Aufrufe mit NULLkönnen dazu führen, dass der Compiler (zu eifrig) spätere NULLÜberprüfungen optimiert .

MOVE_ARRAYFügt einen sicheren und praktischen Helfer zum Verschieben potenziell überlappender Bereiche von Array-Einträgen hinzu.
Es leitet die Elementgröße ab, multipliziert automatisch und sicher, um die Größe in Bytes zu erhalten, führt eine grundlegende Typensicherheitsprüfung durch Vergleichen der Elementgrößen durch und memmove(3)unterstützt im Gegensatz dazu NULLZeiger, wenn 0 Elemente verschoben werden sollen.

#define MOVE_ARRAY(dst, src, n) move_array((dst), (src), (n), sizeof(*(dst)) + \
    BUILD_ASSERT_OR_ZERO(sizeof(*(dst)) == sizeof(*(src))))
static inline void move_array(void *dst, const void *src, size_t n, size_t size)
{
    if (n)
        memmove(dst, src, st_mult(size, n));
}

Beispiele :

- memmove(dst, src, (n) * sizeof(*dst));
+ MOVE_ARRAY(dst, src, n);

Es verwendet das Makro,BUILD_ASSERT_OR_ZERO das eine Abhängigkeit von @condder Erstellungszeit behauptet, als Ausdruck (wobei dies die Bedingung für die Kompilierungszeit ist, die wahr sein muss).
Die Kompilierung schlägt fehl, wenn die Bedingung nicht erfüllt ist oder vom Compiler nicht ausgewertet werden kann.

#define BUILD_ASSERT_OR_ZERO(cond) \
(sizeof(char [1 - 2*!(cond)]) - 1)

Beispiel:

#define foo_to_char(foo)                \
     ((char *)(foo)                     \
      + BUILD_ASSERT_OR_ZERO(offsetof(struct foo, string) == 0))

Nein, memcpy(0,0,0)ist nicht sicher. Die Standardbibliothek wird bei diesem Aufruf wahrscheinlich nicht fehlschlagen. In einer Testumgebung ist jedoch möglicherweise zusätzlicher Code in memcpy () vorhanden, um Pufferüberläufe und andere Probleme zu erkennen. Und wie diese spezielle Version von memcpy () auf NULL-Zeiger reagiert, ist nicht definiert.