AnsiString nach char konvertieren - Problem
-
Hi
habe erfolgreich den AnsiSting in char konvertiert und in eine Datei gespeichert. Habe dafür diesen Quelltext genutzt danke Jansen:char *ch = new char[strText.Length()+1];
strcpy(ch, strText.c_str());Habe jetzt nur ein Problem brim Auslesen der datei und zurück übergeben an die Edit felder. Muss ich da irgend etwas zurück konvertieren. Weil normalerweise müsste es einfach Edit1->Text="Char Variable"; lauten oder???
-
äh ja, und was ist denn jetzt das Problem?
-junix
P.S: Bei einem mit new erstellten Puffer empfiehlt sich das Null-Setzen mittels memset.
-
Nein du brauchst nichts zurückkonvertieren, hast du mal geguckt ob du die Datei auch richtig eingelesen hast? Vielleicht liegt da der Fehler?
-
junix schrieb:
P.S: Bei einem mit new erstellten Puffer empfiehlt sich das Null-Setzen mittels memset.
Naja, da reicht imho schon ein ch[0] = 0; und DonTobias' Beispiel ist insofern auch akzeptabel, da strcpy so nett ist und den Ziel-String terminiert.
-
dschensky schrieb:
junix schrieb:
P.S: Bei einem mit new erstellten Puffer empfiehlt sich das Null-Setzen mittels memset.
Naja, da reicht imho schon ein ch[0] = 0;
nö.
und statt strcpy ist sowieso strncpy empfohlen (pufferüberlauf)
-junix
-
junix schrieb:
dschensky schrieb:
Naja, da reicht imho schon ein ch[0] = 0;
nö.
Aha, das währe mir neu. Wieso nicht?
junix schrieb:
und statt strcpy ist sowieso strncpy empfohlen (pufferüberlauf)
Kommt drauf an. strncpy hat den Vorteil, daß automatisch nur eine maximale Anzahl von Zeichen kopiert wird. Man hat also tatsächlich einen gewissen Schutz vor einem Pufferüberlauf. Nachteil kann u.U. sein, daß immer die maximale Zahl an Zeichen in den Ziel-String geschrieben wird (auffüllen mit 0). Das kostet ein wenig Zeit und überschreibt Daten, die man eventuell noch braucht.
Weiterhin kann strncpy die Prüfung auf einen Pufferüberlauf genauso wenig leisten wie strcopy. Wenn ich also z.B. um die Konsistenz der übergebenen Daten besorgt bin, muß ich die Länge des übergebenen Strings sowieso überprüfen und kann dann auch strcpy benutzen.
-
dschensky schrieb:
junix schrieb:
dschensky schrieb:
Naja, da reicht imho schon ein ch[0] = 0;
nö.
Aha, das währe mir neu. Wieso nicht?
Weil du damit nicht den ganzen Speicherbereich in einen definierten Zustand bringst, sondern lediglich Byte Nummero 1. das hat nur zur Folge, dass der String zunächst mal als Länge 0 durchkommt, während im Rest des Strings noch schrott rumwuselt.
dschensky schrieb:
junix schrieb:
und statt strcpy ist sowieso strncpy empfohlen (pufferüberlauf)
[...]strncpy hat den Vorteil, daß automatisch nur eine maximale Anzahl von Zeichen kopiert wird. Man hat also tatsächlich einen gewissen Schutz vor einem Pufferüberlauf.
Korrekt.
dschensky schrieb:
Nachteil kann u.U. sein, daß immer die maximale Zahl an Zeichen in den Ziel-String geschrieben wird (auffüllen mit 0).
Falsch.
dschensky schrieb:
Das kostet ein wenig Zeit und überschreibt Daten, die man eventuell noch braucht.
Dadurch, dass obige Annahme breits falsch war...
dschensky schrieb:
Weiterhin kann strncpy die Prüfung auf einen Pufferüberlauf genauso wenig leisten wie strcopy.
Sagt ja niemand was von einer Prüfung, er wird schlicht einfach komplett verhindert und unterbunden, da nie längere Strings als MaxLen kopiert werden. Wenn du nun maxLen intelligenter Weise auf die Länge des Zielstrings - 1 Byte setzt, dann ist ein Pufferüberlauf schlicht nichtmehr möglich.
dschensky schrieb:
Wenn ich also z.B. um die Konsistenz der übergebenen Daten besorgt bin, muß ich die Länge des übergebenen Strings sowieso überprüfen und kann dann auch strcpy benutzen.
Falsch.
-junix
-
junix,
junix schrieb:
das hat nur zur Folge, dass der String zunächst mal als Länge 0 durchkommt, während im Rest des Strings noch schrott rumwuselt.
Stimmt, ist aber völlig irrelevant.
Definition: Ein C-String ist ein mit Null abgeschlossenes Feld von Zeichen. Jede Funktion für die Manipulation von C-Strings richtet sich nach dieser Definition. Jeder, der die Daten in den dahinter liegenden Zeichen als sinnvolle Informationen zu interpretieren versucht, ist selbst schuld. Eine Terminierungs-Null genügt also völlig.junix schrieb:
dschensky schrieb:
Nachteil kann u.U. sein, daß immer die maximale Zahl an Zeichen in den Ziel-String geschrieben wird (auffüllen mit 0).
Falsch.
Falsch ist Falsch. Hier ein Ausschnutt aus der CBuilder-Hilfe:
CB-Hilfe zu strncpy schrieb:
Copies a given number of bytes from one string into another, truncating or padding as necessary.
Beispiel:
char* src = "Hallo Welt!"; char dest[20]; strncpy(dest, src, 14);Man beachte, daß "dest" nach den 10 Zeichen von "src" bis zum 14. Zeichen mit Nullen aufgefüllt wird.
junix schrieb:
dschensky schrieb:
Wenn ich also z.B. um die Konsistenz der übergebenen Daten besorgt bin, muß ich die Länge des übergebenen Strings sowieso überprüfen und kann dann auch strcpy benutzen.
Falsch.
Hey, sag das doch nicht dauernd!
Wenn ein Nutzer ein neues Passwort eingibt und das Programm dieses einfach mal so kürzt und dann übernimmt und der Nutzer sich dann das nächste mal nicht anmelden kann, ist das für den Nutzer alles andere als frei von Widersprüchen. Nimmt das Programm aber eine Prüfung der Länge des Strings vor, kann es auf die Fehleingabe reagieren, wenn das Passwort zu lang ist oder aber einfach strcpy benutzten, wenn es kurz genug ist.
-
dschensky schrieb:
junix schrieb:
das hat nur zur Folge, dass der String zunächst mal als Länge 0 durchkommt, während im Rest des Strings noch schrott rumwuselt.
Stimmt, ist aber völlig irrelevant.
Definition: Ein C-String ist ein mit Null abgeschlossenes Feld von Zeichen. Jede Funktion für die Manipulation von C-Strings richtet sich nach dieser Definition. Jeder, der die Daten in den dahinter liegenden Zeichen als sinnvolle Informationen zu interpretieren versucht, ist selbst schuld. Eine Terminierungs-Null genügt also völlig.Stimmt natürlich... Solange man nicht mit Zeigern rumspielt....
dschensky schrieb:
junix schrieb:
dschensky schrieb:
Nachteil kann u.U. sein, daß immer die maximale Zahl an Zeichen in den Ziel-String geschrieben wird (auffüllen mit 0).
Falsch.
Falsch ist Falsch. Hier ein Ausschnutt aus der CBuilder-Hilfe:
CB-Hilfe zu strncpy schrieb:
Copies a given number of bytes from one string into another, truncating or padding as necessary.
Stimmt. Den Padding-Teil hatte ich überlesen. Hab das mal genauer mit dem Debugger angeschaut: Tatsächlich wird erst strlen, dann strcat und dann memset aufgerufen... naja der Zeitverlust hierbei ist nach wie vor minimal.
dschensky schrieb:
junix schrieb:
dschensky schrieb:
Wenn ich also z.B. um die Konsistenz der übergebenen Daten besorgt bin, muß ich die Länge des übergebenen Strings sowieso überprüfen und kann dann auch strcpy benutzen.
Falsch.
Hey, sag das doch nicht dauernd!
Nur wenns passt.
dschensky schrieb:
Wenn ein Nutzer ein neues Passwort eingibt und das Programm dieses einfach mal so kürzt und dann übernimmt und der Nutzer sich dann das nächste mal nicht anmelden kann, ist das für den Nutzer alles andere als frei von Widersprüchen.
tritt dieser Fall ein, hast du offensichtlich was falsch gemacht.
dschensky schrieb:
Nimmt das Programm aber eine Prüfung der Länge des Strings vor, kann es auf die Fehleingabe reagieren,
Hat dir dasjemand verboten?
dschensky schrieb:
wenn das Passwort zu lang ist oder aber einfach strcpy benutzten, wenn es kurz genug ist.
Falls dus noch nicht gemerkt hast: Es geht meistens nciht darum, dass eine Benutzereingabe beim Eintritt in das Programm fehler auslösen kann, sondern dass der Programmierer Fehler gemacht hat bei der Verarbeitung des Strings. Dabei hilft alerdings strncpy das zu vermeiden.
-junix