xyz_s Funktionen auch für ANSI C ?

_matze

/rant/ schrieb:

doch wenn ich ein Zitat eines Users "ms doof`?" anführe, so habe ich jeweils meine Zweifel, wie ernst es gemeint ist.

Ja, kann schon sein. Ist ja auch egal, wir haben beide Recht und fertig!

supertux

/rant/ schrieb:

MSDN über strncpy, _strncpy_l, wcsncpy, _wcsncpy_l, _mbsncpy & _mbsncpy_l schrieb:

"No return value is reserved to indicate an error."

Mit den _s Varianten gibt es definierte Rückgabewerte für Fehler...

mag sein, auch die glib setzt errno den meisten Fehlern entsprechend. Aber in 99% der Fälle wirst du damit nix anfangen können.

*rant*

_matze schrieb:

/rant/ schrieb:

doch wenn ich ein Zitat eines Users "ms doof`?" anführe, so habe ich jeweils meine Zweifel, wie ernst es gemeint ist.

Ja, kann schon sein. Ist ja auch egal, wir haben beide Recht und fertig!

supertux schrieb:

/rant/ schrieb:

MSDN über strncpy, _strncpy_l, wcsncpy, _wcsncpy_l, _mbsncpy & _mbsncpy_l schrieb:

"No return value is reserved to indicate an error."

Mit den _s Varianten gibt es definierte Rückgabewerte für Fehler...

mag sein, auch die glib setzt errno den meisten Fehlern entsprechend. Aber in 99% der Fälle wirst du damit nix anfangen können.

Richtig. Vor allem sind die Fehler, welche damit "behandelt" werden, von der Kategorie, welche in sauberen Programmen nicht vorkommen sollten. Was macht man, wenn ein solcher Fehler gefunden wird? Man hat keine andere Wahl, als ihn so zu beheben, dass man danach auch die normalen Funktionen benutzen könnte

MfG

pointercrash**

Bin weder C- noch Standard- Freund, aber dank beider haben die Worte "Redesign" und "Abkündigung" (von Controllerfamilien) ihren Schrecken verloren, ich kann auf Source- Ebene mit vertretbarem Aufwand zwischen Plattformen migrieren und skalieren.

Microsoft hat von je her versucht, jeden marktrelevanten Standard mit Extensions zu korrumpieren, um ihn an die eigene Plattform zu binden. Java und der tuckige J#- Klon samt fettem .NET- Unterbau sind typische Beispiele dafür. Sogar HTML wurde einer Zwangsmassage unterzogen, die man akzeptiert hat, weil der IE6/7 zeitweilig über 90% Marktanteil hatte. Ziemlich frisch: Die MS- Office- Formate als allgemeiner Standard - wie ist das passiert? Glücklicherweise interessiert sich MS nicht mehr für C.

Die Situation besteht so seit fast 30 Jahren und war eher entwicklungshindernd, deswegen haben Vorbehalte gegen eine "Aufbesserung" der Standards ebenfalls schon "Historie", von "MS- Zeugs" kategorisch die Finger zu lassen, schon fast Lifestyle- Status.

rüdiger

Die BSD Leute haben ja noch die l-Varianten. Die glibc Leute wollten sich weder auf irgend was bisher festlegen und da ein neuer C Standard irgend wo noch in den Sternen steht, würde ich mir da erst einmal keine großen Hoffnungen machen.

Tim schrieb:

man: strncpy, man: strncat, ...

strncpy ist zB fundamental kaputt.

_matze

rüdiger schrieb:

strncpy ist zB fundamental kaputt.

Aha, Begründung?

char str[10];
strncpy (str, "Ein klein wenig zu lang...", sizeof str); // <- str ist nicht terminiert

@ ruediger: Stringhandling in C war nie wirklich schön. Fundamental kaputt ist aber trotzdem übertrieben, das Attribut gehört gets() ganz alleine

PS: Und wer in C sicher mit Strings hantieren will, baut sich halt seine eigene Stringklas^^^^funktionen.

pointercrash**

Tim schrieb:

@ ruediger: Stringhandling in C war nie wirklich schön. Fundamental kaputt ist aber trotzdem übertrieben, das Attribut gehört gets() ganz alleine

Ne, Du kannst mit fast allen Stringfunktionen ein Konstrukt (um ein Byte verzählt, upps) zerknallen, gets() macht das nur offensichtlicher. Wenn Du uralte DDCJs durchwühlst, besteht der Grundvorwurf darin, Strings nicht als Basistyp integriert zu haben, andere feiern das als Heldentat

Tim schrieb:

PS: Und wer in C sicher mit Strings hantieren will, baut sich halt seine eigene Stringklas^^^^funktionen.

Genau dafür brauche ich eigentlich keine "standardisierte", "sourceportable" Sprache, wenn dann doch alles wieder an mir hängenbleibt.

Shade Of Mine

_matze schrieb:

rüdiger schrieb:

strncpy ist zB fundamental kaputt.

Aha, Begründung?

weil du selber haendisch jedesmal den string terminaten musst. ziemlicher schwachsinn. und das padding mit 0 ist auch sehr daemlich.

dann hast du ploetzlich code wie

strncpy(trg, src, n);
if(trg[n-1]!=0) {
  //buffer zu klein
}
trg[n-1]=0;

aber der preis geht natuerlich an gets() fuer die duemmste funktion ever
generell finde ich das string handling in c aber nicht wirklich schlimm. es hat seine vorteile.

wirklich schlimm war dagegen das fehlen eines snprintf...

@pointercrash:
es ist schon ein kleiner unterschied ob ich garantiert einen buffer overflow habe (gets) oder selber einen fehler machen muss um einen zu bekommen (strncpy).