C/C++ - Strings kopieren

Das Forum für Programmierer und Systemadmins. Von Shell-, Perl- und PHP-Scripts bis zur objektorientierten Programmierung mit C++.

C/C++ - Strings kopieren

Beitragvon Thomas13 » So 10 Apr, 2005 17:34

Hallo,

gibt es ein Workaround Strings zu kopieren, ohne die Include-Datei "string.h" zu benutzen ?

Ich möchte den Inhalt von "string_a" nach "string_b" kopieren...


Danke im Vorraus.
Thomas13
Neu im Board
Neu im Board
 
Beiträge: 1
Registriert: So 10 Apr, 2005 17:30

Beitragvon dfx » So 10 Apr, 2005 17:46

Code: Alles auswählen
void my_strcpy(char *dest, const char *src) {
    while ((*dest++ = *src++));
}


bzw könntest du ja auch das strcpy() der c library verwenden, ohne string.h zu includen... ;)
xDSL unlimited 2.320 kbit/s
Bild
Bild
dfx
Board-User Level 3
Board-User Level 3
 
Beiträge: 1368
Registriert: Do 15 Jan, 2004 19:22
Wohnort: graz

Beitragvon ulrich » Mo 11 Apr, 2005 09:34

man sollte unterscheiden:
c-strings: eine array von char, dessen letztes element immer ein 0-byte ist
c++ string: ein objekt der klasse std::string, header string

dfx' ansatz ist nicht wirklich sicher: vergiß das '\0' am ende und die schleife läuft durch dein RAM, bis sie zufällig ein 0-byte findet, oder das programm mit einer zugriffsverletzung abstürzt.

wenn du nicht ganz triftige gründe hast, string.h zu vermeiden, dann ist programmieren auf einem höheren abstraktionsniveau immer vorzuziehen.

bezüglich strcpy: "Because strcpy does not check for sufficient space in strDestination before copying strSource, it is a potential cause of buffer overruns. Consider using strncpy instead."

@dfx: zumindest in VS.net ist strcpy in string.h bzw. cstring, nicht in stdlib.h bzw. cstdlib
ulrich
Senior Board-Mitglied
Senior Board-Mitglied
 
Beiträge: 287
Registriert: Do 13 Nov, 2003 14:27

Beitragvon dfx » Mo 11 Apr, 2005 09:49

ulrich hat geschrieben:dfx' ansatz ist nicht wirklich sicher: vergiß das '\0' am ende und die schleife läuft durch dein RAM, bis sie zufällig ein 0-byte findet, oder das programm mit einer zugriffsverletzung abstürzt.

wenn du einen kaputten string kopierst, _soll_ das programm möglichst crashen. das strcpy() der c lib verhält sich genauso, weil das per definition die funktionsweise von strcpy() ist. einen derartigen fehler anders abzufangen ist außerdem gar nicht möglich.
@dfx: zumindest in VS.net ist strcpy in string.h bzw. cstring, nicht in stdlib.h bzw. cstdlib

was ich gemeint habe: du kannst strcpy() bzw. jede andere funktion einer library verwenden, ohne den entsprechenden header zu includen. in den headern sind ja nur die prototypen deklariert; wenn du diese prototypen selbst in deinem programm deklarierst, kannst du die funktionen ohne dem entsprechenden include verwenden.
xDSL unlimited 2.320 kbit/s
Bild
Bild
dfx
Board-User Level 3
Board-User Level 3
 
Beiträge: 1368
Registriert: Do 15 Jan, 2004 19:22
Wohnort: graz

Beitragvon ulrich » Mo 11 Apr, 2005 10:02

dfx hat geschrieben:wenn du einen kaputten string kopierst, _soll_ das programm möglichst crashen.

eigentlich nicht, zumindest nicht, wenn die entwicklung abgeschlossen ist. außerdem: stichwort buffer overflow attacke.
dfx hat geschrieben:das strcpy() der c lib verhält sich genauso, weil das per definition die funktionsweise von strcpy() ist. einen derartigen fehler anders abzufangen ist außerdem gar nicht möglich.

doch, indem du vorher festlegst, wie lang dein string maximal sein darf, dann darauf achtest, daß die char[] deines quell- und zielstrings wirklich so groß sind und schließlich strncpy (mit 'n') verwendest.
dfx hat geschrieben:was ich gemeint habe: du kannst strcpy() bzw. jede andere funktion einer library verwenden, ohne den entsprechenden header zu includen. in den headern sind ja nur die prototypen deklariert

ah so. ja, natürlich kannst du deine eigenen vorwärtsdeklarationen schreiben, aber was wäre ein grund dafür?

grüße und nix für ungut ;) ,
ulrich
ulrich
Senior Board-Mitglied
Senior Board-Mitglied
 
Beiträge: 287
Registriert: Do 13 Nov, 2003 14:27

Beitragvon dfx » Mo 11 Apr, 2005 10:31

ulrich hat geschrieben:
dfx hat geschrieben:wenn du einen kaputten string kopierst, _soll_ das programm möglichst crashen.

eigentlich nicht, zumindest nicht, wenn die entwicklung abgeschlossen ist. außerdem: stichwort buffer overflow attacke.

das hat mit buffer overflows nix zu tun. du hast gesagt, wenn im quellstring die terminierende null fehlt. wenn das vorkommt, ist das ein definitiver programmierfehler (fehler des programmierers!), der in einem fertigen programm ("wenn die entwicklung abgeschlossen ist") nie auftreten darf. falls er doch auftritt, tätest du besser daran, das programm sauber crashen zu lassen (damit du auf den fehler draufkommst), anstatt den fehler irgendwie verschleiern zu versuchen.
dfx hat geschrieben:das strcpy() der c lib verhält sich genauso, weil das per definition die funktionsweise von strcpy() ist. einen derartigen fehler anders abzufangen ist außerdem gar nicht möglich.

doch, indem du vorher festlegst, wie lang dein string maximal sein darf, dann darauf achtest, daß die char[] deines quell- und zielstrings wirklich so groß sind und schließlich strncpy (mit 'n') verwendest.

das betrifft nur das überschreiben des zielpuffers. wie schon gesagt ist eine fehlende null im _quell_puffer ein ganz anderer fehler. die maximale länge des quellpuffers braucht nicht angegeben zu werden, da diese durch die terminierende null bereits festgelegt ist. wenn diese fehlt, ist der fehler beim anlegen des quellstrings gemacht worden, und das ist (möglicherweise/wahrscheinlich) an einer ganz anderen stelle des programms passiert. durch strncoy() verhindest du zwar, daß du über den zielpuffer hinaus schreibst, du würdest aber immer noch _lesend_ über den quellpuffer hinausschiessen.
ja, natürlich kannst du deine eigenen vorwärtsdeklarationen schreiben, aber was wäre ein grund dafür?

keine ahnung, aber der OP hat gefragt, ob er strings kopieren kann, ohne string.h zu includen, und so würde das gehen. er hat nicht gefragt, wie man strings kopieren kann, ohne die funktionen der c lib zu verwenden. ;)
xDSL unlimited 2.320 kbit/s
Bild
Bild
dfx
Board-User Level 3
Board-User Level 3
 
Beiträge: 1368
Registriert: Do 15 Jan, 2004 19:22
Wohnort: graz

Beitragvon ulrich » Mo 11 Apr, 2005 11:18

dfx hat geschrieben:
ulrich hat geschrieben:
dfx hat geschrieben:wenn du einen kaputten string kopierst, _soll_ das programm möglichst crashen.

eigentlich nicht, zumindest nicht, wenn die entwicklung abgeschlossen ist. außerdem: stichwort buffer overflow attacke.

das hat mit buffer overflows nix zu tun. du hast gesagt, wenn im quellstring die terminierende null fehlt. wenn das vorkommt, ist das ein definitiver programmierfehler (fehler des programmierers!), der in einem fertigen programm ("wenn die entwicklung abgeschlossen ist") nie auftreten darf. falls er doch auftritt, tätest du besser daran, das programm sauber crashen zu lassen (damit du auf den fehler draufkommst), anstatt den fehler irgendwie verschleiern zu versuchen.

es muß kein programmierfehler in dem sinn sein. möglicherweise liest jemand strings aus einer datei, und hat dabei vergessen, die länge zu beschränken und überschreibt so die letze null. natürlich ist das auch ein programmierfehler, aber einer der u.u. recht schwer zu bemerken ist...
außerdem, verschleiert imho ein "komischer" string in irgendeiner ausgabe oder datei weniger als eine access violation vom OS. außer natürlich, du hast den quellcode und kannst bei einer av in den debugger springen.
dfx hat geschrieben:
dfx hat geschrieben:das strcpy() der c lib verhält sich genauso, weil das per definition die funktionsweise von strcpy() ist. einen derartigen fehler anders abzufangen ist außerdem gar nicht möglich.

doch, indem du vorher festlegst, wie lang dein string maximal sein darf, dann darauf achtest, daß die char[] deines quell- und zielstrings wirklich so groß sind und schließlich strncpy (mit 'n') verwendest.

das betrifft nur das überschreiben des zielpuffers. wie schon gesagt ist eine fehlende null im _quell_puffer ein ganz anderer fehler. die maximale länge des quellpuffers braucht nicht angegeben zu werden, da diese durch die terminierende null bereits festgelegt ist. wenn diese fehlt, ist der fehler beim anlegen des quellstrings gemacht worden, und das ist (möglicherweise/wahrscheinlich) an einer ganz anderen stelle des programms passiert. durch strncoy() verhindest du zwar, daß du über den zielpuffer hinaus schreibst, du würdest aber immer noch _lesend_ über den quellpuffer hinausschiessen..

nun, würde ich c programmieren, würde ich's beispielsweise so machen:
const unsigned N = 100;
char quelle[N] = {0};
char ziel[N] = {0};
/*...*/
strncpy(ziel, quelle, N);

nun, mir und dir, dfx, sicher auch, fallen noch einige möglichkeiten ein, was hier wieder schiefgehen könnte...
:) bin ich froh, daß ich (in c++) std::string verwenden kann.
ulrich
Senior Board-Mitglied
Senior Board-Mitglied
 
Beiträge: 287
Registriert: Do 13 Nov, 2003 14:27


Zurück zu PROGRAMMIER FORUM

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste