ich habe das kleine Problem dass ich eine Binärdatei
schreiben muss - Wie das öffnen und beschreiben eines binären Filestreams funktioniert ist mir bekannt.

Ich verwende einen Buffer der in x Runden immer mit y Byte erweitert werden soll, das Problem ist, dass in diesen Buffer auch binäre Nullen kopiert werden sollen.

char* buffer = new char[n];
char* abc = new char[y];

for(int i = 0; i < x; i++){
    abc = FUNKTION();
    strcat(buffer, abc);
}

//Schreibe den Buffer in Datei

Da abc NULL-Terminatoren als Zeichen enthalten kann kann ich strcat nicht verwenden, da diese Funktion an einem solchen Zeichen angekommen die Arbeit abbricht.

Ich wäre für jede Hilfe dankbar

MfG Xeno

Was spricht gegen ein paar geile STL-Container?

"geil"

Hacker schrieb:

Was spricht gegen ein paar geile STL-Container?

"geil"

Mööp Mööp, STL rockt
Oder das ist Geschmackssache - ich find auch nicht alles gut.

Das ganze soll die Endstufe einer Verschlüsselung werden.
Die einzelnen Blöcke (immer multiple von 64-Bit) sollen aneinander gehängt und weggeschrieben werden.

Hmm über einen Vector hatte ich nachgedacht, aber ich weiß nicht wie man den Inhalt in eine Datei schreiben könnte...

Mit &v[0] oder v.data()? Welchen Algorithmus implementierste denn? AES?

*KMT
AUTSCH ok da hätte ich wirklich dran denken sollen^^
Danke für das Öffnen meines geistigen Auges

Ne nicht AES, ist eine Eigenentwicklung die ich seit fast einem Jahr plane und nun endlich Implementiere

Vielen Dank euch allen

Ne nicht AES, ist eine Eigenentwicklung die ich seit fast einem Jahr plane und nun endlich Implementiere

Interessant. Ich hoffe du weist entweder was du da tust (irgendwie bezweifel ich das :)), oder du willst den nicht in irgendetwas Sicherheitsrelevantem einsetzen?

Xenogenesis schrieb:

Hmm über einen Vector hatte ich nachgedacht, aber ich weiß nicht wie man den Inhalt in eine Datei schreiben könnte...

Mit &v[0] oder v.data()?

Bitte was? C++11? Oder seit wann hat std::vector eine solche Member-Funktion?

C++11?

Wie man auch in jeder Referenz nachgucken könnte..

cooky451 schrieb:

Xenogenesis schrieb:

Hmm über einen Vector hatte ich nachgedacht, aber ich weiß nicht wie man den Inhalt in eine Datei schreiben könnte...

Mit &v[0] oder v.data()?

Bitte was? C++11? Oder seit wann hat std::vector eine solche Member-Funktion?

c++11

Ansonsten... was spricht gegen memcpy() und selber mitzählen?

Hacker schrieb:

cooky451 schrieb:

Xenogenesis schrieb:

Hmm über einen Vector hatte ich nachgedacht, aber ich weiß nicht wie man den Inhalt in eine Datei schreiben könnte...

Mit &v[0] oder v.data()?

Bitte was? C++11? Oder seit wann hat std::vector eine solche Member-Funktion?

c++11

cooky451 schrieb:

Hacker schrieb:

C++11?

Wie man auch in jeder Referenz nachgucken könnte..

Bei meiner Lieblingsreferenz gab es keine solche Member-Methode. Ich werde jetzt für die nächste Zeit wohl zu cppreference wechseln müssen... ist aktueller.

Also sagen wir so, das ganze kommt in mehreren Applikationen und auch Projekten anderer zum Einsatz.

char* buffer = new char[n];
char* abc = new char[y];

for(int i = 0; i < x; i++){
    abc = FUNKTION();
    strcat(buffer, abc);
}

Das ist echt wenig an Code. Wie sieht FUNCTION aus? Warum reservierst du per new[] Speicher und überschreibst den Zeiger später mit "abc="? Warum überhaupt new[]?

Tipp: Wenn du glaubst, new[] und delete[] benutzen zu müssen, liegst du sehr wahrscheinlich falsch.

#include <iterator>
#include <vector>
#include <iostream>

template<class OutputIterator>
void func(OutputIterator oi)
{
  *oi++ = 'W';
  *oi++ = 'T';
  *oi++ = 'F';
  *oi++ = '?';
  *oi++ = '!';
}

int main()
{
  using namespace std;
  vector<char> buffer;
  for(int i = 0; i < 5; i++) {
    func(back_inserter(buffer));
  }
  buffer.push_back('\0');
  cout << &buffer[0] << endl;
}

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!

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?

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.

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

Warum?

AES ist aber keine Vollbitverschlüsselung!

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

Ja, irgendwie ist die URL zensiert.

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.

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?

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 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.