[Allegro] Etwas für C-Programmierer: strcpy() vs. memmove()

[Fischer, Thomas]

Lieber Herr Eversberg,

herzlichen Dank für die instruktiven Ausführungen.
Bei mir bleibt aber noch eine Frage offen.

1. Am Anfang dieser Debatte stand m.E. das Problem, dass unsere kombinierte HANS-Suche nicht wie gewünscht funktionierte, weil - so analysierte Herr Berger - acon (ein?) Zeichen bei der Verarbeitung der Suche verschluckte.
2. Dies führte er auf das strcpy-Verhalten zurück, die von Ihnen mit Visual Studio produzierte acon.exe (v.33.4) zeigte dieses Verhalten, nicht aber die erneuerte jetzt aktuelle Version von acon.exe.

Damit ergibt sich die Frage: war  die Analyse von Herrn Berger falsch, ging das fehlende Zeichen also auf andere Weise als durch strcpy verloren? Oder hat Ihr Compiler in dieser Situation doch ein unsicheres strcpy eingebaut, das bei Überschneidung von Quelle und Ziel fehlerhafte Ergebnisse lieferte?

Mit freundlichen Grüßen
Thomas Fischer


> -----Ursprüngliche Nachricht-----
> Von: Allegro [mailto:allegro-bounces at biblio.tu-bs.de] Im Auftrag von
> Bernhard Eversberg
> Gesendet: Montag, 2. Dezember 2013 11:48
> An: Allegro-C Diskussionsliste
> Betreff: [Allegro] Etwas für C-Programmierer: strcpy() vs. memmove()
>
>
> In einem nichtöffentlichen Disput vorige Woche mit Berger schälte sich
> heraus, daß es wohl Compiler gibt (speziell unter Ubuntu), die ein
> Problem machen mit der Funktion strcpy():
> Das Ergebnis eines Aufrufs  strcpy(a,b)  ist laut der Literatur über C
> "undefined" (ohne Fehlermeldung), wenn die Strings a und b sich
> überlappen. Man mag sich an den Kopf fassen, aber so steht's da.
>
> Kurz und gut, um nicht den gesamten Austausch hier zu reproduzieren,
> waren wir hier immer von der Mutmaßung ausgegangen, gestützt jedoch
> auf das bekannte Buch von Kernighan und Ritchie, daß die Sache
> unproblematisch sei, wenn  b = a+n  ist mit nichtnegativem n.
> Anders gesprochen, wenn ein Teilbereich innerhalb von a
> nach vorn gezogen werden soll. Nie zeigte sich ein Problem damit.
> In anderen möglicherweise kritischen Fällen hatten wir das etwas
> umständlichere  memmove()  benutzt, wie es die Literatur rät.
> (Z.B. im Falle a>b mit a-b<strlen(b) wäre, wiederum nach K&R beurteilt,
> mit einem Debakel zu rechnen!)
>
> Nun also scheinen Bergers Beobachtungen unsere also wohl doch naive
> Annahme zu widerlegen.
>
> Was also tun, war die Frage, denn es gibt viele hundert Vorkommnisse
> von strcpy in unseren Quellen! Alle überprüfen?
>
> Auf die einfachste, nächstliegende Lösung kamen wir zuletzt:
> Wir definieren eine Funktion  stcopy(a,b), die nichts
> anderes tut, als  memmove(a,b,strlen(b)+1)  auszulösen, was in
> jedem Falle klappt. Nun müssen wir nur noch in allen Quellen
> die Ersetzung von  "strcpy("  durch  "stcopy("  vornehmen. Das ist
> schlichte Routine-Editierung und geht schnell. Exemplarisch wurde
> das mit acon schon gemacht und funktioniert ohne merkliche
> Performance-Einbuße, wie sich auch bei einem gezielten Test
> bestätigte. Dies mag auch noch vom Compiler abhängen, aber mit
> Visual-C++ ist es so.
> Die C-Quellen von "atools" (also srch, import, index, qrix) werden
> in gleicher Weise entschärft.
>
> Das publizierte Gesamtpaket V33 ist zwar noch ohne diese Änderung
> kompiliert, das macht aber nichts, weil der Visual-C++ damit ja
> eben keine Zicken macht!
>
> Wir melden Vollzug, sobald die Änderungen erledigt und im SVN sind.
> Danach  werden dann *diese* Problemstellen ihre Compilerabhängigkeit
> eingebüßt haben. Andere Problemstellen harren noch ihrer Entlarvung als
> solcher.
>
> B.E.
>
>
>
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro