strcpy vs. strcpy_s

Viele dieser String-Funktionen sind saublöd konstruiert und sorgen seit 
Jahrzehnten massgeblich für die berüchtigten Buffer-Overflows.

Dass strcpy() über das Ende vom Ziel hinaus schreibt ist einigermassen 
offensichtlich. Der Tip mit strncpy ist jedoch auch eine Falle. Denn 
wenn das "n" erreicht wird ist kein \0 hinten dran, was von vielen 
Programmierern vergessen wird, mit entsprechend hässlichen Folgen. Bei 
strncat wiederum vergisst man gern, dass sich das "n" nicht aufs Ziel 
sondern auf die Quelle bezieht und folglich den Zielpuffer auch wieder 
nicht absichert.

Daher gibt es mittlerweile einige Extrafunktionen um die übelsten Löcher 
zu stopfen und Microsoft strcpy_s ist eine davon. Aber m.E. sollte man 
für einigermassen sicheres Programmieren diese ganze Lib entweder 
garnicht oder nur mit grosser Vorsicht benutzen. Ein Ansatz besteht 
darin, sich auf Basis von ein paar solcher Funktionen eigene Funktionen 
zu definieren, die man dann konsequent an Stelle der Originale 
verwendet. Und so ist man dann auch nicht von mehr oder weniger 
proprietären Erweiterungen abhängig.

Besser ist es freilich, wenn man gleich C++ mit der entsprechenden 
Stringverarbeitung verwendet.

tata wrote:
> Mit strcpy_s bindest du dich an MS und einige wenige andere Libs,
> als Alternative wäre strncpy zu nennen, dass ist in der string.h
> bzw cstring.h vorhanden und gehört vermutlich zum C-Standard.

Diese _s-Varianten werden sehr wahrscheinlich zum kommenden Standard 
gehören.
ISO/IEC TR 24731
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1225.pdf