NULL enthaltende Char* kopieren

[_cu]

Ethon schrieb:

Was spricht gegen etwas wie AES, das auch sicher funktioniert?
Wie ist dein Background in Zahlentheorie etc? Kannst du formell die Sicherheit deines Algorithmus beweisen?

AES ist aber keine Vollbitverschlüsselung!

[pumuckl]

Xenogenesis schrieb:

char* buffer = new char[n];

hustbaer schrieb:

std::vector<char> wie schon vorgeschlagen wurde ist sicher die bessere Wahl.

Ich will nicht kleinlich sein. Aber sollten binäre Daten nicht in unsigned char s dargestellt werden?

[cooky451]

pumuckl schrieb:

Ich will nicht kleinlich sein. Aber sollten binäre Daten nicht in unsigned char s dargestellt werden?

Sollten - ist aber ziemlich unüblich. Siehe z.B. ifstream::read, memcpy, etc.

[TyRoXx]

pumuckl schrieb:

Ich will nicht kleinlich sein. Aber sollten binäre Daten nicht in unsigned char s dargestellt werden?

Warum?

[knivil]

_cu schrieb:

AES ist aber keine Vollbitverschlüsselung!

Du meinst sowas hier: http://www.kryptochef.de/ ? lol

Ja, irgendwie ist die URL zensiert.

[krümelkacker]

pumuckl schrieb:

Ich will nicht kleinlich sein. Aber sollten binäre Daten nicht in unsigned char s dargestellt werden?

Jepp, wenn ich binär I/O mache, dann verwende ich irgendwo auch unsigned char und irgendwoanders wird ge reinterpret_cast et. Ich verlass mich einfach darauf, dass das alles klappt und dass, falls die Maschine negative Ganzzahlen nicht per 2er-Komplement darstellt, char wenigstens vorzeichenlos ist, damit all die Bitmuster legal und einen einzigartigen char-Wert ergeben (also ohne die Problematik +/-0). Ich glaube nicht, dass eine solche Garantie direkt im C++ Standard gemacht wird, aber ich kann mir nicht vorstellen, wie man sonst vernünftig per char arbeiten können sollte, wenn man sich nicht mindestens auf eins von beiden (2er-komplement und/oder char ist vorzeichenlos) verlassen kann. Vielleicht folgt diese Garantie auch indirekt aus anderen Bedingungen ... denn es gibt z.b. die Garantie, dass ich einen POD so kopieren kann:

POD x = ...;
POD y;
{
  char const* p = reinterpret_cast<char*>(&x);
  char      * q = reinterpret_cast<char*>(&y);
  for (int i=0; i<sizeof(y); ++i) {
    q[i] = p[i];
  }
}

und ich sehe nicht, wie das vernünftig funktionieren sollte, falls char sowohl vorzeichenbehaftet als auch so etwas wie sign+magnitude oder 1er-komplement verwendet. Da würde ja irgendwie Information verloren gehen, weil zwei verschiedene Bitmuster für die Null verwendet werden, also einmal +0 und einmal -0.

[camper]

krümelkacker schrieb:

Da würde ja irgendwie Information verloren gehen, weil zwei verschiedene Bitmuster für die Null verwendet werden, also einmal +0 und einmal -0.

Solange die Repräsentation des Wertes beim Kopieren erhalten bleibt, sehe ich kein Problem? Wie ist das nochmal bei Gleitkommazahlen, eine negative 0 bleibt dort doch auch beim Kopieren erhalten, oder?

[krümelkacker]

camper schrieb:

Solange die Repräsentation des Wertes beim Kopieren erhalten bleibt, sehe ich kein Problem

Wo wird das garantiert, dass das so ist? Ich habe da tatsächlich mal nach gesucht, bin aber nicht fündig geworden ...

camper schrieb:

Wie ist das nochmal bei Gleitkommazahlen, eine negative 0 bleibt dort doch auch beim Kopieren erhalten, oder?

Wahrscheinlich. Nichts genaues, weiß ich nicht.

[camper]

krümelkacker schrieb:

camper schrieb:

Solange die Repräsentation des Wertes beim Kopieren erhalten bleibt, sehe ich kein Problem

Wo wird das garantiert, dass das so ist? Ich habe da tatsächlich mal nach gesucht, bin aber nicht fündig geworden ...

Ich glaube die Frage ist auch falsch gestellt (und der Vegleich mit Gleitkommazahlen wahrscheinlich irrführend).

Wir haben:

3.9.1 Fundamental types [basic.fundamental]
1 Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic
character set. If a character from this set is stored in a character object, the integral value of that character
object is equal to the value of the single character literal form of that character. It is implementation-defined
whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed.
Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an
unsigned char occupy the same amount of storage and have the same alignment requirements (3.11); that
is, they have the same object representation. For character types, all bits of the object representation participate
in the value representation. For unsigned character types, all possible bit patterns of the value
representation represent numbers. These requirements do not hold for other types. In any particular implementation,
a plain char object can take on either the same values as a signed char or an unsigned char;
which one is implementation-defined.

Das problematische Bitmuster 10000000 (bzw. entsprechnd länger) muss gar keine Zahl darstellen, unabhängig davon muss es aber ein gültiger Wert (non-trapping NaN oder so) sein. Zu sagen das wäre eine negative Null ist ggf. sowieso irreführend, dann der beobachtete Zahlenwert ist ohnehin erst das, was nach Konvertierung in int (o.ä.) antsteht; einfach deshalb, weil bei fast allen anwendbaren Operatoren erst einmal eine integrale Promotion ansteht.

3.9 Types [basic.types]
...
2 For any object (other than a base-class subobject) of trivially copyable type T, whether or not the object
holds a valid value of type T, the underlying bytes (1.7) making up the object can be copied into an array
of char or unsigned char.40 If the content of the array of char or unsigned char is copied back into the
object, the object shall subsequently hold its original value.

Im Beispiel wir memcpy verwendet, allerdings eben nur als Beispiel. Soweit mir bewusst, definiert der Standard nicht ausdrücklich, was Kopieren hier genau bedeuten soll, mir scheint aber, dass eine einfache Zuweisung da mit eingeschlossen sein soll.

[krümelkacker]

Danke für's Raussuchen und Kommentieren. Da muss mir vorher der Unterschied zwischen "Zahl" und "Wert" entgangen sein.