NULL enthaltende Char* kopieren

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

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.

cooky451

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()? Welchen Algorithmus implementierste denn? AES?

@cooky451

*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

cooky451

Xenogenesis schrieb:

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?

Sone

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?

cooky451

Hacker schrieb:

C++11?

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

unskilled

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

hustbaer

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

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

Sone

unskilled schrieb:

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.

Ja mit dem Vector funktioniert es dann auch

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

Ethon

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?

krümelkacker

Xenogenesis schrieb:

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;
}

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.