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

Question

Ich kenne mich mit dem C-Standard nicht so gut aus, also bitte ich um Nachsicht mit mir.

Ich würde gerne wissen, ob die Norm garantiert, dass memcpy(0,0,0) sicher ist.

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

Aber können wir davon ausgehen, dass sich die Speicherbereiche hier überschneiden?

Answer 1

Ich besitze einen Entwurf der C-Norm (ISO/IEC 9899:1999), und darin stehen einige interessante Dinge über diesen Aufruf. Zunächst einmal heißt es (§7.21.1/2) in Bezug auf memcpy dass

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

Der hier angegebene Hinweis weist darauf hin:

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

Es sieht also so aus, dass nach der C-Spezifikation der Aufruf von

memcpy(0, 0, 0)

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

Allerdings wäre ich sehr erstaunt, wenn eine tatsächliche Umsetzung von memcpy Die meisten intuitiven Implementierungen, die mir einfallen, würden überhaupt nichts tun, wenn man sagt, dass man null Bytes kopieren soll.

Answer 2

Nur zum Spaß, die Release-Notes für gcc-4.9 zeigen, dass der Optimierer diese Regeln nutzt und zum Beispiel die Bedingung in

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

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

Ich bin etwas zwiegespalten, was das Verhalten von gcc-4.9 angeht; das Verhalten mag zwar standardkonform sein, aber die Möglichkeit, memmove(0,0,0) aufzurufen, ist manchmal eine nützliche Erweiterung dieser Standards.

Answer 3

Sie können auch diese Verwendung von memmove gesehen in Git 2.14.x (Q3 2017)

Ver Commit 168e635 (16. Juli 2017), und 1773664 übertragen , f331ab9 übertragen , festlegen 5783980 (15 Jul 2017) von René Scharfe ( rscharfe ) .
(Zusammengefasst von Junio C. Hamano -- gitster -- en 32f9025 übertragen , 11. August 2017)

Es verwendet eine Hilfsmakro MOVE_ARRAY die die Größe berechnet auf der Grundlage der angegebenen Anzahl von Elementen für uns und unterstützt NULL Zeiger, wenn diese Zahl Null ist.
Rohe memmove(3) Anrufe mit NULL kann den Compiler dazu veranlassen, später (übereifrig) zu optimieren NULL Kontrollen.

MOVE_ARRAY fügt ein sicheres und bequemes Hilfsmittel zum Verschieben von sich möglicherweise überschneidenden Bereichen 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 Typsicherheitsprüfung durch, indem es Elementgrößen vergleicht und im Gegensatz zu memmove(3) es unterstützt NULL Zeiger, 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 die Makro BUILD_ASSERT_OR_ZERO die eine Abhängigkeit zur Erstellungszeit behauptet, als Ausdruck (mit @cond ist die Bedingung zur Kompilierzeit, 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))

Answer 4

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