C/C++ - Strings kopieren

[Thomas13]

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.

[dfx]

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

[ulrich]

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

[dfx]

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.

[ulrich]

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

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

[dfx]

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.

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.

[ulrich]

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.

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.