MOin Ich möchte eine Funktion hinzufügen, bei der die beiden nicht identischen Namen mit einer Zeichenfolge verbunden werden. Dafür möchte ich meine eigene Funktion verwenden (Stringverbinden), die zwei Strings als Eingabeparameter enthält und einen dritten String generiert, der die beiden durch ein & -Zeichen verbundenen Strings enthält, aber wie mache ich das? Und ja, ich möchte zwei Strings ohne die strcmp-Funktion vergleichen. Hier ist mein Code: #include <stdio.h> int main (){ char a[100]; char b[100]; int i; printf("please enter the first name:"); scanf("%99s", a); printf("please enter the second name:"); scanf("%99s", b); i=0; while(a[i] == b[i] && a[i]!='\0') i++; if ( a == b){ return 1; } else { return 0; } return 0; }
:
Gesperrt durch Moderator
Arduino? https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/ Gruss Chregu
Man kann Strings nicht direkt miteinander verbinden, ohne die daten im Speicher zu verschieben. Mache a größer, so dass auch b und der '&' Zeichen hinein passen.
1 | char a[201]; |
2 | char b[100]; |
3 | |
4 | ... (Eingabe) ... |
5 | |
6 | strlcat(a, "&", sizeof(a)); |
7 | strlcat(a, b, sizeof(a)); |
Beitrag #6524738 wurde von einem Moderator gelöscht.
Du möchtest also 2 unterschiedliche Strings verbinden, aber nur wenn sie unterschiedlich sind? Mein Vorschlag: char compareStrings(char[100] strE, char[100] strZ){ int i=0; while((strE[i] != '\0' || strZ[i] != '\0') & i<100){ if(strE[i] != strZ[i]) return 0x00 // sprich falls nicht gleich i++; } return 0x01 //da der PC Programm Counter es bis hier hin geschafft hat, sind die beiden Strings gleich } int main(){ //.. dein Code char[200] c; if(compareStrings(a, b) == 0x01){ //.. verknüpfen int i =0 while(a[i] != '\0'){ i++;} for(int y=0; y< i; y++){ c[y] += a[y]; } c[i] = ' '; c[i+1] = '&'; c[i+2] = ' '; for(int y=0; y< i; y++){ c[y+i+3] += b[y]; } } //... c ausgeben printf(c) }
Wado U. schrieb: > der die > beiden durch ein & -Zeichen verbundenen Strings enthält, aber wie mache > ich das? snprintf lesen.
char compareStrings(char[100] strE, char[100] strZ){ int i=0; while((strE[i] != '\0' || strZ[i] != '\0') & i<100){ if(strE[i] != strZ[i]) return 0x00 // sprich falls nicht gleich i++; } return 0x01 //da der PC Programm Counter es bis hier hin geschafft hat, //sind die beiden Strings gleich } int main(){ //.. dein Code char[200] c; if(compareStrings(a, b) == 0x01){ //.. verknüpfen int i =0 while(a[i] != '\0'){ i++;} for(int y=0; y< i; y++){ c[y] += a[y]; } c[i] = ' '; c[i+1] = '&'; c[i+2] = ' '; for(int y=0; y< i; y++){ c[y+i+3] += b[y]; } } //... c ausgeben printf(c) }
Nick M. schrieb: > danke bitte schrieb: >>C-Code > sowieso nicht lesenswert. wow, die Recursion funktioniert hier sogar bei der Code-Formatierung.
bitte danke schrieb: > strcpy(dest_str, name1); > strcat(dest_str, " & "); > strcat(dest_str, name2); Ist leider nicht sicher gegen Pufferüberlauf. Außerdem braucht strcat unnötige Schritte, um das bisherige Stringende zu finden. Meine Lösung habe ich hier beschrieben: Beitrag "Re: strcpy mit automatischer Längenprüfung" Der Aufruf sieht dann so aus: char *t; int len; char *lim=dest_buf+sizeof(dest_buf); t=stpcpylim(dest_buf,name1,lim); t=stpcpylim(t," & ",lim); t=stpcpylim(t,name2,lim); len=t-dest_buf;
:
Bearbeitet durch User
#define strBufferLen 200 char dest[strBufferLen]; snprintf(dest, strBufferLen, "%s&%s", "A", "B"); Ist schon jämmerlich hier!
MaWin schrieb: > Gruss Chregu Hat ja lange gedauert, bis sich einer der Psychopathen hier mal verplappert.
MaWin schrieb: > MaWin schrieb: >> Gruss Chregu > > Hat ja lange gedauert, bis sich einer der Psychopathen hier mal > verplappert. Denkst du, den Trick glaubt jemand? Einfach einen anderen Namen drunter schreiben und schon kann man alles auf mysteriöse "Psychopathen" schieben.
Jobst Q. schrieb: > habe ich hier beschrieben: > > Beitrag "Re: strcpy mit automatischer Längenprüfung"
1 | char* stpcpylim(char *t, const char *s,const char * lim){ |
2 | |
3 | lim--; |
4 | while(*s && t<lim) *t++=*s++; |
5 | *t=0; |
6 | return t; |
7 | }
|
Welche Rolle spielt der dritte Parameter lim? Er spielt doch eine (falsche) Rolle nur wenn "lim < strlen(str)" (der String wird abgeschnitten). D.h. ich kann lim auf 100.000 setzen - es ist egal. Hauptsache der destination-String kann alle Teilstrings aufnehmen. Wozu brauch ich diesen Wert dann?
1 | #define KEINE_AHNUNG 2000
|
2 | |
3 | char* names[] = { "Alfred ", |
4 | "Else ", |
5 | "Rita ", |
6 | "Michael ", |
7 | "Fr. Suhrbier " }; |
8 | |
9 | char dest[128] = ""; |
10 | |
11 | char* p = |
12 | stpcpylim (dest, names[0], dest + KEINE_AHNUNG); |
13 | |
14 | for (size_t i = 1; i < 5; i++) { |
15 | p = stpcpylim (p, names[i], p + KEINE_AHNUNG); |
16 | }
|
17 | |
18 | puts (dest); |
Nick M. schrieb: > snprintf(dest, strBufferLen, "%s&%s", "A", "B"); > Ist schon jämmerlich hier! Ja, diese erheblich langsamere Lösung die auf einen Pattern-Interpreter basiert und viel mehr RAM belegt ist jämmerlich.
Stefan ⛄ F. schrieb: > Ja, diese erheblich langsamere Lösung die auf einen Pattern-Interpreter > basiert und viel mehr RAM belegt ist jämmerlich. Langsamer als was? Vorallem, warum "erheblich"? Du hast dafür bestimmt einen Beleg den du hier bereitwillig zeigst. Kannst dir mal überlegen wie "aufwändig" das "pattern" aufzulösen ist. Das "pattern" (der Begriff pattern wird bei regex verwendet) ist tatsächlich ein Format. Und das löst sich sehr einfach auf. Also nix mit Deinem "Pattern-Interpreter" Dieses selbstgeschriebene strcpy von weiter oben ist wohl Ausdruck des hohen Niveaus hier. Derjenige hat noch nie was von strncpy gehört.
Stefan ⛄ F. schrieb: > Ja, diese erheblich langsamere Lösung die auf einen Pattern-Interpreter > basiert und viel mehr RAM belegt ist jämmerlich. Und warum ist das so relevant, dass man gleich eine eigene Stringmanipulation aufziehen muss, statt die libc zu verwenden?
MaWin schrieb: > Stefan ⛄ F. schrieb: >> Ja, diese erheblich langsamere Lösung die auf einen Pattern-Interpreter >> basiert und viel mehr RAM belegt ist jämmerlich. > > Und warum ist das so relevant, dass man gleich eine eigene > Stringmanipulation aufziehen muss, statt die libc zu verwenden? Ich habe keine eigene Stringmanipulation aufgezogen. Ich habe nur strlcat() von BSD benutzt, welches auch in der avr-libc enthalten ist.
Stefan ⛄ F. schrieb: > Ich habe keine eigene Stringmanipulation aufgezogen. Ich habe nur > strlcat() von BSD benutzt, welches auch in der avr-libc enthalten ist. Ja, ich habe das bewusst etwas überspitzt dargestellt. Das war im Kontext mit den schwachsinnigen selbstgestrickten "effizienten" "Lösungen" davor zu verstehen. Das Argument, dass etwas immer effizienter sein muss, kann man immer weiter treiben. Am Ende muss man es dann in ASM implementieren. Es ist völlig in Ordnung eine Lösung mit snprintf oder ähnlichem zu verwenden, wenn es keine Rolle spielt wie effizient das ist.
Nick M. schrieb: > Langsamer als was? Vorallem, warum "erheblich"? Du hast dafür bestimmt > einen Beleg den du hier bereitwillig zeigst. Du darfst dir gerne zwei Testprogramm schreiben und sie profilen, wenn du Belege sehen willst. Das hier ist ein Diskussionsforum, keine wissenschaftliche Studie. Hier wird nicht alles belegt. Du hast deinen Widerspruch schließlich auch nicht belegt. Abgesehen davon bräuchten wir für einen Beleg zumindest mal die Info, auf welcher Plattform das laufen soll.
Stefan ⛄ F. schrieb: > Ich habe nur strlcat() von BSD benutzt Das strlcat ist bestimmt erheblich langsamer, weil es mindestens einmal strlen() aufrufen muss.
Stefan ⛄ F. schrieb: > Ich habe keine eigene Stringmanipulation aufgezogen. Ich habe nur > strlcat() von BSD benutzt, welches auch in der avr-libc enthalten ist. Der Code vom Themenersteller läuft ja recht offensichtlich auf einem System, auf dem die C-Standardbibliothek verfügbar ist. Sonst wär nix mit printf() und scanf(). Dann kann man das Problem doch auch sehr einfach mit Funktionen dieser Standardbibliothek lösen. Hat den Vorteil, dass die Lösung dann super portabel ist. :-)
Stefan ⛄ F. schrieb: > Abgesehen davon bräuchten wir für einen Beleg zumindest mal die Info, > auf welcher Plattform das laufen soll. Na ganz offensichtlich nicht auf einem Bare Metal Mikrocontroller, sonden auf einem System das über eine Standardein- und ausgabe verfügt. Wird so sein wie immer, der Themenersteller hätte in einem anderen Unterforum posten sollen (PC-Programmierung) und hat nicht richtig hingeschaut.
Stefan ⛄ F. schrieb: > Hier wird nicht alles belegt. Du hast deinen > Widerspruch schließlich auch nicht belegt. Achso, dann ist das halt einfach eine Behauptung von dir ohne Wert. Damit ist also der Beitrag wertlos. Das war aber auch so für mich erkennbar. Aber dennoch Danke, dass du es den Anderen auch noch erklärst. Und welchen Widerspruch von mir hast du dir beiläufig aus dem Hut gezogen? Stefan ⛄ F. schrieb: > Abgesehen davon bräuchten wir für einen Beleg zumindest mal die Info, > auf welcher Plattform das laufen soll. Das hast doch du schon definiert. Es muss wohl AVR sein. Beleg: Stefan ⛄ F. schrieb: > Ich habe nur > strlcat() von BSD benutzt, welches auch in der avr-libc enthalten ist.
can't see sharp schrieb: > Welche Rolle spielt der dritte Parameter lim? > Ist doch in dem Link beschrieben: lim ist ein Zeiger auf das erste Byte, dass nicht beschrieben werden darf, in den meisten Fällen buf+sizeof(buf). Der Vorteil des Grenzpointers statt einer Längenangabe ist, dass er über alle Aktionen auf dem Puffer gleich bleibt und nicht für jedes Anhängen neu berechnet werden muss. > Er spielt doch eine (falsche) Rolle nur wenn "lim < strlen(str)" (der > String wird abgeschnitten). Ja, es ist nur eine Begrenzung, um gegen Pufferüberläufe abzusichern. Denn anders als hier in den Beispielen sind es in der Praxis meist keine Stringkonstanten sondern noch unbekannte Strings. Am Abschneiden ist nichts falsch, immerhin bleibt es ein gültiger String. Natürlich funktioniert das kopieren auch mit beliebig großem lim. Du kannst auch deinen Steckdosenkreis mit 63A absichern statt mit 16A, die Geräte an den Steckdosen funktionieren trotzdem. Nur wenn ein Kurzschluß geschieht und dein Haus abfackelt, hast du die Chance zu begreifen, welchen Zweck eine richtig dimensionierte Sicherung hat.
Jobst Q. schrieb: > Am Abschneiden ist nichts falsch Ja doch. Dann sind die Daten korrumpiert. So etwas kann dann gerne auch mal ausgenutzt werden, wenn ein Nutzer beliebige Daten in einen String schreiben darf und das Programm dann etwas wichtiges anhängt, was dann abgeschnitten wird. Wenn die Truncation nicht geprüft wird, kann das bedeuten, dass der Nutzer Kontrolle über Dinge bekommt, die er eigentlich nicht haben dürfte.
Hier ist der Beweis:
1 | stefan@stefanpc:~/Downloads$ gcc test1.c |
2 | stefan@stefanpc:~/Downloads$ time ./a.out |
3 | Herr von Ribbek auf Ribbek&im Havelland |
4 | |
5 | real 0m0,563s |
6 | user 0m0,563s |
7 | sys 0m0,000s |
8 | |
9 | stefan@stefanpc:~/Downloads$ gcc test2.c |
10 | stefan@stefanpc:~/Downloads$ time ./a.out |
11 | Herr von Ribbek auf Ribbek&im Havelland |
12 | |
13 | real 0m0,727s |
14 | user 0m0,723s |
15 | sys 0m0,004s |
test1 mit strlcat() ist auf dem Laptop schneller, als test2 mit snprintf(). Ich habe hier den Quelltext von strlcat() aus der avr-libc kopiert, weil ich gerade keinen Bock darauf hatte, herauszufinden, wie man diese BSD Bibliothek unter Linux einbindet. In test1 musste zusätzlich einen Aufruf von strncpy() einfügen, damit das ganze in der Schleife wiederholbar wird. Der TO bräuchte diese Zeile nicht, bei ihm wäre es also noch schneller. Seid ihr jetzt zufrieden?
Stefan ⛄ F. schrieb: > Seid ihr jetzt zufrieden? 200 ms schneller für 10 Mio Aufrufe. Das macht 20 Nanosekunden schneller pro String-Verbindung. Was machst du mit all dieser gewonnenen Zeit?
> von MaWin (Gast)25.12.2020 16:41 > von MaWin (Gast)26.12.2020 10:23 > von MaWin (Gast)26.12.2020 11:51 > von MaWin (Gast)26.12.2020 12:07 > von MaWin (Gast)26.12.2020 12:30 > von MaWin (Gast)26.12.2020 12:38 Meine Fresse, hier dreht ein Psychopath aber wieder auf, kaum dass sich einer von denen enttarnt hat.
> Was machst du mit all dieser gewonnenen Zeit? Du versuchst gerade krampfhaft, mich ins lächerliche zu ziehen. Ich habe einen guten Lösungsansatz gezeigt und bewiesen, dass er deutlich effizienter ist. Welchen Vorteil der TO daraus zieht, bleibt ihm überlassen. > 200 ms schneller für 10 Mio Aufrufe. Auf meinem Laptop! Du kannst gerne testen, wie groß der Unterschied auf einem AVR ist. Wenn dir das Timing unwichtig ist, muss man sich schon fragen, warum du dann einen Beweis verlangt hast. Kannst du das erklären?
Bei kürzeren Strings wird der Unterschied übrigens größer:
1 | stefan@stefanpc:~/Downloads$ gcc test1.c |
2 | stefan@stefanpc:~/Downloads$ time ./a.out |
3 | A&B |
4 | |
5 | real 0m0,249s |
6 | user 0m0,250s |
7 | sys 0m0,000s |
8 | |
9 | stefan@stefanpc:~/Downloads$ gcc test2.c |
10 | stefan@stefanpc:~/Downloads$ time ./a.out |
11 | A&B |
12 | |
13 | real 0m0,680s |
14 | user 0m0,676s |
15 | sys 0m0,004s |
MaWin schrieb: >> von MaWin (Gast)25.12.2020 16:41 >> von MaWin (Gast)26.12.2020 10:23 >> von MaWin (Gast)26.12.2020 11:51 >> von MaWin (Gast)26.12.2020 12:07 >> von MaWin (Gast)26.12.2020 12:30 >> von MaWin (Gast)26.12.2020 12:38 > > Meine Fresse, hier dreht ein Psychopath aber wieder auf, kaum dass sich > einer von denen enttarnt hat. Wer sagt das? Achja, das war von MaWin (Gast)26.12.2020 12:46 Wenn das kein Beweis ist...
Stefan ⛄ F. schrieb: > Hier ist der Beweis: Der Beweis dafür, dass die AVR-Bibliothek auf einer 64Bit Intel CPU schneller läuft? War das die Frage? Oder war die Frage, wie man 3 strings möglichst holprig verbindet? Dann passt die Lösung die dafür 3 Zeilen braucht ganz gut.
Nick M. schrieb: > Der Beweis dafür, dass die AVR-Bibliothek auf einer 64Bit Intel CPU > schneller läuft? Ja Nick, mir war schon klar dass du in Wahrheit gar keinen Beweis sehen wolltest. Dir geht es nur darum, meinen Vorschlag schlecht zu reden. Je mehr Informationen ich dir liefere, umso mehr Angriffspunkte findest du darin. Den Vergleich mit einem AVR darfst du gerne selber machen. Ich bin nicht so bescheuert, dir auch noch diesen Gefallen zu tun. > Ist schon jämmerlich hier!
MaWin schrieb: > Jobst Q. schrieb: >> Am Abschneiden ist nichts falsch > > Ja doch. Dann sind die Daten korrumpiert. > > So etwas kann dann gerne auch mal ausgenutzt werden, wenn ein Nutzer > beliebige Daten in einen String schreiben darf und das Programm dann > etwas wichtiges anhängt, was dann abgeschnitten wird. Wenn die > Truncation nicht geprüft wird, kann das bedeuten, dass der Nutzer > Kontrolle über Dinge bekommt, die er eigentlich nicht haben dürfte. Das wäre nur möglich, wenn der String nicht abgeschnitten wäre, also wenn kein Null-Zeichen ans Ende geschrieben würde. Und natürlich wäre es kein Problem,zu überprüfen, ob der String abgeschnitten wurde. Einfach durch Vergleich des Rückgabewerts mit lim.
Stefan ⛄ F. schrieb: > Ja Nick, mir war schon klar dass du in Wahrheit gar keinen Beweis sehen > wolltest. Dir geht es nur darum, meinen Vorschlag schlecht zu reden. Kann ich bei dir auch sagen. Aber damit du zufrieden bist: Eine Lösung die 3 Zeilen braucht ist allemal besser als eine die 1 Zeile braucht. 3 Zeilen sind besser lesbar, machen ein kürzeres Programm und sind jedenfalls besser wenn man das allerletzte aus der CPU rausquetschen muss. Wobei es wieder Du bist, der definiert dass Geschwindigkeit das Ziel ist. > Je mehr Informationen ich dir liefere, umso mehr Angriffspunkte findest > du darin. Das liegt daran, dass du mit jedem Mal neue Ramenbedingungen definierst die von niemanden so gefordert wurden. Du lieferst hier keine Informationen, sondern Behauptungen. Behauptungen die wiederum auf Behauptungen von dir basieren. Stefan ⛄ F. schrieb: > Den Vergleich mit einem AVR darfst du gerne selber machen. Ich bin nicht > so bescheuert, dir auch noch diesen Gefallen zu tun. Wozu soll ich mir jetzt irgend so eine AVR-Plattform kaufen? Um was zu beweisen? Deine Behauptung dass das Zielsystem ein AVR ist mit einer lib die nicht dem C-Standard entspricht. Ehrlich sowas ist mir einfach die Zeit nicht wert. Die kannst du gerne verplempern, komm einfach wieder mit einer neuen Behauptung und basier deine "Beweise" darauf.
Ist gut, dein Vorschlag ist der einzig sinnvolle. Alle anderen sind
> jämmerlich
wie du sagst. Und jetzt geh wieder spielen.
Stefan ⛄ F. schrieb: > Und jetzt geh wieder spielen. Ich spiele nicht, im Gegensatz zu dir und machen Anderen hier.
Jobst Q. schrieb: > Einfach durch Vergleich des Rückgabewerts mit lim. Wie soll das gehen? Der Rückgabewert wird immer < lim sein. lim liegt ja sogar außerhalb des Arrays. (was auch interessant ist) Man muss voher prüfen, ob source-String in den destination-String reinpasst. Und wenn er reinpasst, dann kann man auch strcpy nehmen. (oder stpcpy oder ...)
Hier mal ganz konkrete Beispiele für jämmerlichen Code in dem thread: Lukas S. schrieb: > char compareStrings(char[100] strE, char[100] strZ){ > int i=0; > while((strE[i] != '\0' || strZ[i] != '\0') & i<100){ > if(strE[i] != strZ[i]) return 0x00 // sprich falls nicht gleich > i++; > } > return 0x01 //da der PC Programm Counter es bis hier hin geschafft > hat, //sind die beiden Strings gleich > } * Warum zur Hölle steht da char[100] in der Parameterliste? Gibts keine pointer mehr? * Warum liefert die Funktion als Ergebnis einen char und kein bool zurück? Char zwingt dem Compiler ein Byte auf, egal wie ineffektiv das ist. Bool ist native und effektiver. * Warum geht die Schleife nur bis 100? Wird die Funktion per copy & paste & modify dann auf 50 Zeichen angepasst? Warum wird strE und strZ immer per index zugegriffen? Muss das so ineffektiv sein? Lukas S. schrieb: > for(int y=0; y< i; y++){ c[y] += a[y]; } So wird also ein string angehängt. Wusste ich nicht, dass das bedeutet strings zu addieren. Aber bitte! Ich bin mir auch sicher, dass ein Memcopy deutlich effektiver ist. Aber für das Kriterium "jämmerlich" schon gut genug. Wado U. schrieb: > if ( a == b){ > return 1; a und b sind strings. Will er schaun ob die pointer auf den gleichen String zeigen? Stefan ⛄ F. schrieb: > strlcat(a, "&", sizeof(a)); > strlcat(a, b, sizeof(a)); Erfüllt nicht die Forderung nach einem dritten String, sondern ist destruktiv auf a. Blöd wenn das eine Konstante ist. Jobst Q. schrieb: > t=stpcpylim(dest_buf,name1,lim); Muss sich sogar eine eigene Kopierfunktion für Strings bauen.
Nick M. schrieb: > Erfüllt nicht die Forderung nach einem dritten String Du meinst "deine" Forderung. Dazu passt dieses Zitat sehr gut: Beitrag "Darum diskutieren wir lieber"
Stefan ⛄ F. schrieb: > Nick M. schrieb: >> Erfüllt nicht die Forderung nach einem dritten String > > Du meinst "deine" Forderung. Ich bin nicht Wado. Also ist deine Behauptung nur wieder nichts als eine falsche Behauptung: Wado U. schrieb: > die zwei Strings > als Eingabeparameter enthält und einen dritten String generiert, der die > beiden durch ein & -Zeichen verbundenen Strings enthält, aber wie mache > ich das?
Eiverstanden, möglicherweise habe ich Wado missverstanden. Leider beteiligt er sich nicht an der Diskussion. Es erscheint mir recht sinnlos, ohne ihn darüber zu streiten, was er gemeint oder nicht gemeint haben könnte. Deswegen lass uns das hier mal besser ruhen lassen, bis er sich wieder einklinkt.
can't see sharp schrieb: > Jobst Q. schrieb: >> Einfach durch Vergleich des Rückgabewerts mit lim. > > Wie soll das gehen? Der Rückgabewert wird immer < lim sein. lim liegt ja > sogar außerhalb des Arrays. (was auch interessant ist) > Wenn der Rückgabewert == lim-1 ist, ist der Puffer randvoll, also der String höchstwahrscheinlich abgeschnitten. > Man muss voher prüfen, ob source-String in den destination-String > reinpasst. > Muss man eben nicht. Und dass du destination-String schreibst, zeigt, wie wenig du von Stringbearbeitung verstehst. Man schreibt nicht in einen String, sondern in einen Speicherbereich, einen Puffer. Ein String ist in C der Inhalt eines Puffers von einer Anfangsadresse bis zu einem Nullbyte. Davon kann es viele in einem Puffer geben.
Nick M. schrieb: > Stefan ⛄ F. schrieb: > Nick M. schrieb: > Erfüllt nicht die Forderung nach einem dritten String > > Du meinst "deine" Forderung. > > Ich bin nicht Wado. Also ist deine Behauptung nur wieder nichts als eine > falsche Behauptung: > > Wado U. schrieb: > die zwei Strings > als Eingabeparameter enthält und einen dritten String generiert, der die > beiden durch ein & -Zeichen verbundenen Strings enthält, aber wie mache > ich das? Treffer und versenkt.
Nick M. schrieb: > Jobst Q. schrieb: >> t=stpcpylim(dest_buf,name1,lim); > > Muss sich sogar eine eigene Kopierfunktion für Strings bauen. Was soll ich sonst machen, wenn mir die Lib-Funktionen nicht gut genug sind?
Jobst Q. schrieb: > Was soll ich sonst machen, wenn mir die Lib-Funktionen nicht gut genug > sind? Hä? Einfach meine Postings lesen und nicht nur den Pawlowschen Minus-Click-Reflex ausleben? Es gibt eine Funktion die alle Forderungen erschlägt. Setzt halt eine gewisse Bewandtnis mit C und deren Bibliotheken voraus. Und ich nehme auch nur die C-Standard-Bibliothek her. Meine Referenz dafür ist P.J. Plauger. Und nicht irgendein Arduino-Geblödle. https://en.wikipedia.org/wiki/P._J._Plauger
Jobst Q. schrieb: > Muss man eben nicht. Ok, die Größe von lim ist immer string_anfang+42 oder wie? Jobst Q. schrieb: > char *lim=dest_buf+sizeof(dest_buf); Welche Größe hast du für dest_buf genommen und warum? Ohne strlen-Funktion hast du da doch entweder zuviel (Platzverschwendugn) oder zu wenig (String passt nicht rein).
MaWin schrieb: > Treffer und versenkt. Ja, geil was? Was für ein Niveau! Noch tiefer geht es nicht mehr.
Jobst Q. schrieb: >> Muss sich sogar eine eigene Kopierfunktion für Strings bauen. > > Was soll ich sonst machen, wenn mir die Lib-Funktionen nicht gut genug > sind? Und damit du Gelegenheit hast hier was dazuzulernen: strncpy (char * dest, const char * src, size_t n); The strncpy() function copies at most n characters from the string addressed by src to the char array addressed by dest, ... Schon im ersten Halbsatz sieht man, dass es eine geeignete Funktion gibt. n darf größer sein als strlen(src), es wird nur bis zum 0x00 kopiert. #define buffSize 200 char destStr[buffSize] = ""; strncpy(destStr, "A", buffSize);
Stefan ⛄ F. schrieb: > Was für ein Niveau! Noch tiefer geht es nicht mehr. Vergiss nicht, dass du den Steuerknüppel nach vorne gedrückt hast!
Nick M. schrieb: > strncpy(destStr, "A", buffSize); Jetzt fehlt nur noch, dass zu zum Anhängen weiterer Zeichenketten strlcat() empfiehlst. SCNR
Nick M. schrieb: > Vergiss nicht, dass du den Steuerknüppel nach vorne gedrückt hast! Nein, du hast damit angefangen. Ich frische dein schwaches Gedächtnis erneut auf: Nick M. schrieb: > Ist schon jämmerlich hier! Wer andere derart beleidigt, muss mit der natürlichen Reaktion klar kommen.
Stefan ⛄ F. schrieb: > Was für ein Niveau! Noch tiefer geht es nicht mehr. Na ja, der Psychopath der schon den ganzen thread seine geistige Beschränktheit demonstriert.
Stefan ⛄ F. schrieb: >> strncpy(destStr, "A", buffSize); > > Jetzt fehlt nur noch, dass zu zum Anhängen weiterer Zeichenketten > strlcat() empfiehlst. Was soll denn jetzt diese blöde Witz? Ich hab dem Jobst Q. bewiesen, dass es für sein selbstgebasteltes stpcpylim eine Funktion gibt, die sogar die gleiche Parameterreihenfolge hat. Aber er jammert, dass es sowas nicht gibt. Das ist alles. Kein Grund für weitere Vermutungen für dich. Aber du kannst dich hier gerne weiter blamieren. Stefan ⛄ F. schrieb: > Nick M. schrieb: >> Ist schon jämmerlich hier! > > Wer andere derart beleidigt, muss mit der natürlichen Reaktion klar > kommen. Den jämmerlichen Code hab ich gepostet und kommentiert, du kannst ihn dir gerne fachlich schönsaufen oder schönjammern.
Nick M. schrieb: > Und damit du Gelegenheit hast hier was dazuzulernen: > strncpy (char * dest, const char * src, size_t n); So eine Bombe lege ich mir nicht ins Nest. strncpy setzt nichtmal ein Nullbyte ans Ende, wenn src länger als n ist. Man bekommt also nichtmal einen gültigen String, sondern einfach nur Murks. Das darfst du noch dazulernen. Außerdem hat es dieselbe Schwäche wie strcpy, dass es einen Wert zurückgibt, der eh schon bekannt ist. Viel nützlicher ist aber der Zeiger auf das Ende wie bei stpcpy. Da fehlt aber noch die Sicherheit gegen Pufferüberlauf.
Jobst Q. schrieb: > Nick M. schrieb: >> Und damit du Gelegenheit hast hier was dazuzulernen: >> strncpy (char * dest, const char * src, size_t n); > > So eine Bombe lege ich mir nicht ins Nest. strncpy setzt nichtmal ein > Nullbyte ans Ende, wenn src länger als n ist. Dafür hängt es unnötig viele Nullbytes an, wenn src kürzer als n ist.
Jobst Q. schrieb: > So eine Bombe lege ich mir nicht ins Nest. strncpy setzt nichtmal ein > Nullbyte ans Ende, wenn src länger als n ist. Das darfst du dann nach der weiteren Montage machen. > Viel nützlicher ist aber der Zeiger auf das Ende wie bei stpcpy. Wenn man von einer Addition überfordert ist, ja.
Nick M. schrieb: > Jobst Q. schrieb: >> So eine Bombe lege ich mir nicht ins Nest. strncpy setzt nichtmal ein >> Nullbyte ans Ende, wenn src länger als n ist. > > Das darfst du dann nach der weiteren Montage machen. Lieber einmal eine gute Funktion schreiben, als hunderte Male beim Aufruf eine schlechte nachbessern. > >> Viel nützlicher ist aber der Zeiger auf das Ende wie bei stpcpy. > > Wenn man von einer Addition überfordert ist, ja. Wenn du addieren willst, musst du erst die Länge ermitteln, also ein zusätzliches strlen(). Das ist bei Funktionen mit Endpointerrückgabe nicht nötig.
Jobst Q. schrieb: >>> Am Abschneiden ist nichts falsch >> >> Ja doch. Dann sind die Daten korrumpiert. >> >> So etwas kann dann gerne auch mal ausgenutzt werden, wenn ein Nutzer >> beliebige Daten in einen String schreiben darf und das Programm dann >> etwas wichtiges anhängt, was dann abgeschnitten wird. Wenn die >> Truncation nicht geprüft wird, kann das bedeuten, dass der Nutzer >> Kontrolle über Dinge bekommt, die er eigentlich nicht haben dürfte. > > Das wäre nur möglich, wenn der String nicht abgeschnitten wäre, also > wenn kein Null-Zeichen ans Ende geschrieben würde. Kompletter Unsinn. Das kommt auf die Daten an und was damit gemacht wird. Du hast behauptet, dass an einem Abschneiden nichts falsch ist. Das ist eine gängige Meinung und sie ist eigentlich immer falsch. Manchmal wird dann ein abgeschnittener String nur angezeigt, was harmlos ist. Manchmal kann es aber auch zu schwerwiegenden Bugs führen.
Jobst Q. schrieb: > Lieber einmal eine gute Funktion schreiben, als hunderte Male beim > Aufruf eine schlechte nachbessern. OK! Lösung 1: Einen Wrapper dazu schreiben (nicht effektiv). Lösung 2: Doch lieber was komplett funktionierendes verwenden das man nicht testen muss -> snprintf() Jobst Q. schrieb: > Wenn du addieren willst, musst du erst die Länge ermitteln, also ein > zusätzliches strlen(). Auch da hast du Recht. Darum verwende ich gleich die einfache Lösung. s.o. Aber jetzt kommt noch was hinterher: Was soll passieren, wenn die 3 Strings nicht ins Ziel passen? Irgendwas abgehacktes? Ein NULL-string? Abgehackt + Fehler-flag? Aus reiner Bosheit fordere ich NULL-String. Jetzt muss man vorher*) strlen() über Alle machen. Und wenn man jeweils strlen hat, dann kann man sowieso gleich memcpy hernehmen. *) In der pessimistischen Lösung. Eine optimistische Lösung**) macht ein strlen() jeweils vor dem jeweiligen string **) Die kann dann gleich mit open parameter list arbeiten. Und ist dann noch näher am snprintf.
MaWin schrieb: > Manchmal kann es aber auch zu schwerwiegenden Bugs führen. Wie soll das geschehen? Die Begrenzung des Strings ist eine Sicherung für Notfälle. Wenn eine Sicherung auslöst, fällt der Strom weg. Dadurch kann Unangenehmes geschehen, aber es ist weniger schlimm, als wenn es im Kurzschlussfall ganz ohne Sicherung wäre.
Jobst Q. schrieb: > Dadurch kann Unangenehmes > geschehen, aber es ist weniger schlimm, als wenn es im Kurzschlussfall > ganz ohne Sicherung wäre. Was passiert eigentlich, wenn man auf einem Mikrocontroller aus der main() rausgeht? Da kann ich es doch gleich krachen lassen für einen Neustart. :-))
Jobst Q. schrieb: > Wie soll das geschehen? Daten wurden abgeschnitten und fehlen nun. Das kann zu Fehlverhalten bei einer folgenden Interpretation der Daten führen.
Nick M. schrieb: > Was passiert eigentlich, wenn man auf einem Mikrocontroller aus der > main() rausgeht? Beim avr-gcc endet die Ausführung in einer leeren Endlosschleife.
Jobst Q. schrieb: > MaWin schrieb: >> Manchmal kann es aber auch zu schwerwiegenden Bugs führen. > > Wie soll das geschehen? Die Daten sind beschädigt und damit korrupt. Fehlerhafte Daten können jede Menge Schaden anrichten. Statt nun beispielsweise die Datei /somefilesystemwithalongname/meinedaten/test.txt wird das ganze Verzeichnis /somefilesystemwithalongname gelöscht, weil im Puffer für mehr nicht Platz war und der Name daher einfach kommentarlos abgeschnitten wurde.
:
Bearbeitet durch User
Rolf M. schrieb: > Die Daten sind beschädigt und damit korrupt. Fehlerhafte Daten können > jede Menge Schaden anrichten. Statt nun beispielsweise die Datei > /somefilesystemwithalongname/meinedaten/test.txt wird das ganze > Verzeichnis /somefilesystemwithalongname gelöscht, weil im Puffer für > mehr nicht Platz war und der Name daher einfach kommentarlos > abgeschnitten wurde. Schön konstruiertes Beispiel. Die Verantwortung dafür liegt aber am Interpreter der Daten, der einfach etwas ausführt, ohne die Plausibilität der Daten zu überprüfen. Ein automatisch generiertes Script auszuführen ist immer riskant. In deinem konstruiertem Beispiel wäre aber auch der Zeilenvorschub mit abgeschnitten worden und damit die nächste Zeile direkt angehängt worden, was entweder eine nicht existierende Datei zum Löschen ergeben hätte oder einen Syntaxfehler beim Interpreter. Das Nichtabschneiden eines Strings, indem keine Endnull gesetzt wird (wie bei strncpy) ist auf jeden Fall weitaus gefährlicher und falscher, weil damit Daten in den String kommen können, die niemanden etwas angehen. Zumal die Begrenzung bei gut dimensionierten Puffergrößen sowie nur in Ausnahmefällen wie Hackerangriffen anspricht. Die neueren Funktionen wie strlcpy, strlcat und snprintf schneiden übrigens auch ab, es ist also nicht allein ein Problem meiner Funktion.
:
Bearbeitet durch User
Jobst Q. schrieb: > Schön konstruiertes Beispiel. Soll ja auch nicht mehr sein als das. Jedenfalls sind unbemerkt abgeschnittene Strings keine gute Idee, sofern es sich um mehr handelt als eine Ausgabe zur Unterhaltung des Benutzers. > Die Verantwortung dafür liegt aber am Interpreter der Daten, der einfach > etwas ausführt, ohne die Plausibilität der Daten zu überprüfen. Nicht immer lässt sich das sicherstellen. Woran erkenne ich denn zuverlässig und 100%iger Sicherheit, ob ein String vollständig ist oder am Ende ein Stück fehlt? > Ein automatisch generiertes Script auszuführen ist immer riskant. Kein Grund, bewusst ein zusätzliches Risiko einzubauen. > In deinem konstruiertem Beispiel wäre aber auch der Zeilenvorschub mit > abgeschnitten worden und damit die nächste Zeile direkt angehängt > worden, was entweder eine nicht existierende Datei zum Löschen ergeben > hätte oder einen Syntaxfehler beim Interpreter. Was für ein Zeilenumbruch? > Das Nichtabschneiden eines Strings, indem keine Endnull gesetzt wird > (wie bei strncpy) ist auf jeden Fall weitaus gefährlicher und falscher, > weil damit Daten in den String kommen können, die niemanden etwas > angehen. Das Problem ist viel mehr, dass durch geschickte Ausnutzung Schadcode zur Ausführung gelangen kann. > Die neueren Funktionen wie strlcpy, strlcat und snprintf schneiden übrigens > auch ab, es ist also nicht allein ein Problem meiner Funktion. Diese Funktionen geben aber alle drei zurück, wie viel sie geschrieben hätten, wenn der Puffer groß genug gewesen wäre. Über einen Vergleich dieses Werts mit der Puffergröße lässt sich damit sehr leicht erkennen, ob der String abgeschnitten wurde oder nicht.
Jobst Q. schrieb: > Schön konstruiertes Beispiel. Die Verantwortung dafür liegt aber am > Interpreter der Daten, der einfach etwas ausführt, ohne die > Plausibilität der Daten zu überprüfen. Der Interpreter kann diese Plausibilität gar nicht vollständig prüfen. /foo ist genau so gültig wie /foo/bar Es geht hier einzig und alleine darum, dass die Aussage, dass abgeschnittene Strings immer harmlos sind, ganz einfach falsch ist. Nicht mehr und nicht weniger. Jobst Q. schrieb: > Das Nichtabschneiden eines Strings, indem keine Endnull gesetzt wird > (wie bei strncpy) ist auf jeden Fall weitaus gefährlicher und falscher, Das hängt ganz von der folgenden Verarbeitung ab. Ein abgeschnittener gültiger String kann genau so gefährlich sein, wie im Beispiel dargelegt wurde.
Rolf M. schrieb: > Diese Funktionen geben aber alle drei zurück, wie viel sie geschrieben > hätten, wenn der Puffer groß genug gewesen wäre. Über einen Vergleich > dieses Werts mit der Puffergröße lässt sich damit sehr leicht erkennen, > ob der String abgeschnitten wurde oder nicht. Bei meiner Funktion lässt sich das mindestens ebenso leicht feststellen: t=stpcpylim(buf, s,lim); if (t==lim-1){gibAlarm("String abgeschnitten");tuIrgendwas();} Das Rückgabeverhalten "wäre, wenn" finde ich eher ein unerwartetes Manko, das die Ermittlung der wirklich beschriebenen Länge bzw des Stringendes erschwert. Aber ich mag diese Mischmasch-Stringfunktionen mit Pointern und Längen als Argumente und Rückgaben eh nicht. Reine Pointerfunktionen sind viel einfacher zu behandeln und dadurch weniger fehleranfällig.
Jobst Q. schrieb: > Bei meiner Funktion lässt sich das mindestens ebenso leicht feststellen: > > t=stpcpylim(buf, s,lim); > if (t==lim-1){gibAlarm("String abgeschnitten");tuIrgendwas();} Wie unterscheidest du zwischen einem String, der genau rein gepasst hat und einem, der abgeschnitten wurde? > Das Rückgabeverhalten "wäre, wenn" finde ich eher ein unerwartetes > Manko, das die Ermittlung der wirklich beschriebenen Länge bzw des > Stringendes erschwert. Was ist daran schwer? Wenn das Ergebnis in den Puffer gepasst hat, ist es genau die wirklich beschriebene Länge. Wenn nicht, habe ich gleich noch die Puffergröße, die ich brauche, damit es reicht und damit auch die Info darüber, ob es gereicht hat oder nicht und wie viele Zeichen abgeschnitten wurden. > Aber ich mag diese Mischmasch-Stringfunktionen mit Pointern und Längen als > Argumente und Rückgaben eh nicht. Reine Pointerfunktionen sind viel einfacher > zu behandeln und dadurch weniger fehleranfällig. Das geht hier natürlich nicht, denn dann müsste die Funktion einen Zeiger zurückgeben, der ggf. weit außerhalb des Zielpuffers liegt.
Jobst Q. schrieb: > Das Rückgabeverhalten "wäre, wenn" finde ich eher ein unerwartetes > Manko, Die Idee dahinter ist, dass der Anwender ein Stringfunktion-Reallocation-Stringfunktion Triple fahren kann. Das ist ziemlich clever und ziemlich effizient. Wenn man die erste Stringfunktion mit einem kleinen lokalen Puffer arbeiten lässt, wird aus der Reallocation auch noch eine normale Allocation. Im Gegensatz dazu ist deine Pointerspielerei sehr eingeschränkt. Schon alleine, weil der Standard Pointer auf den Bereich &Array[0] bis &Array[NR_ELEMS] beschränkt.
Rolf M. schrieb: > Wie unterscheidest du zwischen einem String, der genau rein gepasst hat > und einem, der abgeschnitten wurde? In solchen Fällen mache ich den Puffer immer einfach mindestens ein Zeichen größer als nötig. Danach gehe ich davon aus, dass der String zu groß war, wenn der Puffer voll ist.
Stefan ⛄ F. schrieb: > In solchen Fällen mache ich den Puffer immer einfach mindestens ein > Zeichen größer als nötig. Woher weißt du, wie groß "nötig" ist? Nur für triviale Fälle weißt du das. Oder wenn du vorher alle Teile mit strlen durchzählst. Und um die geht es hier nicht. Wenn du weißt, wie groß das ist, dann brauchst du die Abschneideprüfung überhaupt nicht, weil der Puffer ja so groß wie nötig ist.
MaWin schrieb: > Woher weißt du, wie groß "nötig" ist? Das muss ich so oder so vorgeben. Bei Mikrocontrollern kann ich nicht einfach davon ausgehen, dass String beliebig groß sein können - wegen der begrenzten Ressourcen. Also lege ich z.B. fest, dass eine Eingabe maximal 30 Zeichen lang sein darf, und mache den Puffer 31 Zeichen groß. Wenn ich dann 31 Zeichen empfange, breche ich mit einer Fehlermeldung ab. Bei Systemen die nicht abbrechen können/dürfen muss man eben von vorne herein dafür sorgen, dass ungültige Eingaben unmöglich sind.
Stefan ⛄ F. schrieb: > Das muss ich so oder so vorgeben. Nein. Lies meinen Post über Reallocation. > Bei Mikrocontrollern kann ich nicht einfach davon ausgehen, Es geht hier nicht (nur) um Mikrocontroller. Es geht um den was-wäre-wenn-Returnwert von einigen Stringfunktionen und warum dieser sinnvoll ist. > Bei Systemen die nicht abbrechen können/dürfen muss man eben von vorne > herein dafür sorgen, dass ungültige Eingaben unmöglich sind. Das geht selbstverständlich nicht immer.
Stefan ⛄ F. schrieb: > Also lege ich z.B. fest, dass eine Eingabe maximal 30 Zeichen lang sein > darf, und mache den Puffer 31 Zeichen groß. Wenn ich dann 31 Zeichen > empfange, breche ich mit einer Fehlermeldung ab. außerdem verschwendet das ein Zeichen im Puffer, was mit der stdlib-Funktion nicht verschwendet wäre. Die stdlib-Stringfunktionen sind mit Sicherheit kein Beispiel für guten und sicheren Stil (z.B. gets()). Aber einige Sachen haben sie bei der Entwicklung dieser Funktionen halt auch richtig gemacht.
MaWin schrieb: > Es geht hier nicht (nur) um Mikrocontroller. Dazu würde ich gerne die Antwort von Wado abwarten, denn ich glaube nicht, dass du seine Gedanken lesen kannst. Zumindest ist das gewählte Forum "Mikrocontroller und Elektronik" schon mal ein deutliches Indiz. Ansonsten hätte der Thread in den Bereich "PC-Programmierung" gehört. Aber nichts genaues weiß man nichts.
MaWin schrieb: > Stefan ⛄ F. schrieb: >> In solchen Fällen mache ich den Puffer immer einfach mindestens ein >> Zeichen größer als nötig. > > Woher weißt du, wie groß "nötig" ist? > Nur für triviale Fälle weißt du das. Oder wenn du vorher alle Teile mit > strlen durchzählst. Und um die geht es hier nicht. > > Wenn du weißt, wie groß das ist, dann brauchst du die Abschneideprüfung > überhaupt nicht, weil der Puffer ja so groß wie nötig ist. Es geht bei der Begrenzung um eine Sicherung gegen außergewöhnliche Fälle durch korrupte Eingangsdaten. Bei der elektrischen Absicherung von Steckdosen stört es mich auch nicht, wenn sie schon bei 15,999 A auslöst anstatt bei 16,000 A. Und ich werde auch nicht den gerade fließenden Strom aller Steckdosen messen und summieren, um dann die Sicherung darauf einzustellen.
Egal wie man es dreht und wendet: Man wird immer einen Fall finden, wo eine Lösung nicht optimal ist. Ein paar wenige Individuen suchen sich immer gezielt diese Fälle heraus, um jede Empfehlung die nicht von ihnen selbst kommt, zu zerreden.
Stefan ⛄ F. schrieb: > MaWin schrieb: >> Es geht hier nicht (nur) um Mikrocontroller. > > Dazu würde ich gerne die Antwort von Wado abwarten, denn ich glaube > nicht, dass du seine Gedanken lesen kannst. Willst du damit sagen, dass du es dir anders überlegt hast? Denn weiter oben hast du dich oft genug immer auf den AVR bezogen.
Stefan ⛄ F. schrieb: > Egal wie man es dreht und wendet: Man wird immer einen Fall finden, wo > eine Lösung nicht optimal ist. Weil ihr euch bis jetzt geweigert hab, das Verhalten im Fehlerfall zu definieren.*) So lässt sich wunderbar im Kreis diskutieren. Und dann aus Beleidigtsein noch ein Jammer-Thread dazu starten: Beitrag "Darum diskutieren wir lieber" Ich wette, ich komm damit unter -4. *) Ich hab darauf hingewiesen.
Jobst Q. schrieb: > Bei der elektrischen Absicherung von Steckdosen stört es mich auch nicht, Äpfel und Birnen.
Stefan ⛄ F. schrieb: > um jede Empfehlung die nicht von ihnen selbst kommt, zu zerreden. Nein. Ganz und gar nicht. Bleib bitte bei der Wahrheit. Die Diskussion ging von einer Falschaussage aus. Und zwar davon, dass das Abschneiden von Strings immer harmlos sei.
Nick M. schrieb: > Weil ihr euch bis jetzt geweigert hab, das Verhalten im Fehlerfall zu > definieren. Überlass das mal dem Wado und höre auf, auf den Boden zu stampfen. Ich kann das hören.
Stefan ⛄ F. schrieb: > Nick M. schrieb: >> Weil ihr euch bis jetzt geweigert hab, das Verhalten im Fehlerfall zu >> definieren. > > Überlass das mal dem Wado. Schön, du hast jemanden gefunden der sich nicht mehr dran beteiligt. Du hättest auch den Waldi*) als Verantwortlichen festlegen können. Jedenfalls hat die Festlegung -durch dich- auf AVR ja ganz schön lang gehalten. Ist dir aber jetzt doch ein bissl unangenehm nachdem du nicht drauf eingehst. Oder? Dein Beitrag mit dem Diskutieren ist schon ganz treffend. Nur hab ich erhebliche Zweifel ob du ihn annähernd kapiert hast, oder ihn ansatzweise umsetzt. *) irgend ein Dackel > und höre auf, auf den Boden zu stampfen. Ich kann das hören. Tinitus ist Schei**e, ich weiß.
Nick M. schrieb: > Jedenfalls hat die Festlegung -durch dich- auf AVR ja ganz schön lang > gehalten. Das ist nicht korrekt. Stefan ⛄ F. schrieb: > Ich habe nur strlcat() von BSD benutzt, > welches auch in der avr-libc enthalten ist. Die Festlegung auf AVR hast du daraus abgeleitet, nicht ich. Siehe: Nick M. schrieb: >> Abgesehen davon bräuchten wir für einen Beleg zumindest mal die Info, >> auf welcher Plattform das laufen soll. > Das hast doch du schon definiert. Es muss wohl AVR sein. MaWin schrieb: > Bleib bitte bei der Wahrheit. Ja genau. Seid ihr eigentlich eine Person? So wie ihr euch hier die Bälle gegenseitig zuspielt, erweckt ihr den Eindruck.
Stefan ⛄ F. schrieb: > Nick M. schrieb: >> Jedenfalls hat die Festlegung -durch dich- auf AVR ja ganz schön lang >> gehalten. > > Das ist nicht korrekt. Natürlich nicht... Stefan ⛄ F. schrieb: > strlcat() von BSD benutzt, welches auch in der avr-libc enthalten ist. Stefan ⛄ F. schrieb: > snprintf(). Ich habe hier den Quelltext von strlcat() aus der avr-libc Stefan ⛄ F. schrieb: > einem AVR ist. Wenn dir das Timing unwichtig ist, muss man sich schon Stefan ⛄ F. schrieb: > Den Vergleich mit einem AVR darfst du gerne selber machen. Ich bin nicht Achso, du beziehst dich immer wieder auf AVR und seine lib, aber das hat nichts damit zu tun dass du dich auf den AVR beziehst. Ich verstehe. **ÖRKS** Stefan ⛄ F. schrieb: > MaWin schrieb: >> Bleib bitte bei der Wahrheit. > > Ja genau. Seid ihr eigentlich eine Person? Ich bin ich, MaWin ist manchmal MaWin, manchmal aber nicht MaWin. Besprich das mit MaWin. Jedenfalls beleg ich meine Aussagen durch Zitate. Du könnest auch mal dazu übergehen. Oder liegt es dir nur daran deinen Diskussions-Thread durch dich selbst zu füttern? Also nur der Diskussion halber und deiner eigenen einzigen Wahrheit halber?
Stefan ⛄ F. schrieb: > Seid ihr eigentlich eine Person? So wie ihr euch hier die > Bälle gegenseitig zuspielt, erweckt ihr den Eindruck. Schön, wie du immer wieder versuchst vom Thema abzulenken, oder das Thema zu deinen Gunsten zu verbiegen.
MaWin schrieb: > Stefan ⛄ F. schrieb: >> Seid ihr eigentlich eine Person? So wie ihr euch hier die >> Bälle gegenseitig zuspielt, erweckt ihr den Eindruck. > > Schön, wie du immer wieder versuchst vom Thema abzulenken, oder das > Thema zu deinen Gunsten zu verbiegen. Ach ja, und: Geisterfahrer! Überall Geisterfahrer!
Nick M. schrieb: > Achso, du beziehst dich immer wieder auf AVR und seine lib, aber das hat > nichts damit zu tun dass du dich auf den AVR beziehst. Ich verstehe. Nee, du verstehst gar nichts. Ich habe eine Funktion aus der BSD Bibliothek verwendet. Dass diese zufällig auch in der AVR Bibliothek drin ist, finde ich praktisch, denn ich experimentiere auch mit AVR. Das bedeutet aber keinesfalls, dass ich mich auf AVR festgelegt habe. Ganz im Gegenteil, ich habe den TO nach seiner Plattform gefragt - die hat er uns nur noch nicht genannt. Zu deinen aus dem Zusammenhang gerissenen Zitaten: > Stefan ⛄ F. schrieb: >> strlcat() von BSD benutzt, welches auch in der avr-libc enthalten ist. Da siehst du, dass ich die Funktion von BSD verwendet habe. Im übrigen kannst du sie auch in Linux nutzen, dort ist sie als optionales Paket verfügbar. Ich kann nichts dafür, dass die Funktion in der avr-libc enthalten ist. Das ist halt so. Diesen bezug habe nicht ich hergestellt, sondern die Entwickler der avr-libc. > Stefan ⛄ F. schrieb: >> snprintf(). Ich habe hier den Quelltext von strlcat() aus der avr-libc (kopiert). Es ging darum, die Performance dieser Funktion mit snprintf() zu vergleichen. Ich hätte sie genau so gut aus den BSD Quelltexten kopieren können, denn da kommt sie letztendlich her. Aber da ich nun einmal gerade die avr-libc auf meinem Rechner habe, war es für mich einfacher, von dort zu kopieren. > Stefan ⛄ F. schrieb: >> einem AVR ist. Wenn dir das Timing unwichtig ist, muss man sich schon Hier ging es darum, dass dir der Performance-Unterschied absolut betrachtet auf einem PC zu gering war. Da es in diesem Forum jedoch um Mikrocontroller geht, habe ich dich darum gebeten es auf einem AVR zu testen. Den habe ich exemplarisch genannt. Du kannst genau so gut einen Z80 oder PIC oder was weiß ich nehmen. > Stefan ⛄ F. schrieb: >> Den Vergleich mit einem AVR darfst du gerne selber machen. Ich bin nicht Wie gesagt, der AVR ist hier nur als Beispiel genannt. Die strlcat() Funktion kommt von BSD. Hast du das jetzt endlich verstanden? Du kannst jetzt gerne zusammen mit MaWin noch weitere Lügen suchen wenn du Spaß daran hast. Ich habe keine Lust mehr, an diesem albernen Spielchen teilzunehmen.
Wado: Schreibe mit bitte eine persönliche Nachricht, wenn du das Thema ohne diese beiden Störenfriede fortsetzen möchtest.
Stefan ⛄ F. schrieb: > Wie gesagt, der AVR ist hier nur als Beispiel genannt. Weil du einen hast. Und natürlich ist es gleichzeitig die Begründung dafür eine vom C Standard abweichende Bibliothek zu verwenden. Das ist kein Zufall, das ist deine Entscheidung. Jeder Andere bezieht sich auf den Standard Stefan ⛄ F. schrieb: > Ganz im Gegenteil, > ich habe den TO nach seiner Plattform gefragt - die hat er uns nur noch > nicht genannt. Genau. Und dann hast du dich dazu entschlossen, dass es ein AVR sein muss. Begründung: Weil. Aber jetzt gilt das plötzlich nicht mehr. Begründung: Weil. Und Randbedingungen zu definieren geht auch nicht mehr. Begründung: Deine ganzen Annahmen würden in sich zusammenfallen. Denn es spielt einfach eine Rolle wie die Implementation aussieht wenn Fehlerfälle unterschiedlich behandelt werden. Hab ich weiter oben hingewiesen. Wurde aber anhaltend ignoriert, weil sonst -> Diskussionsthread.
Stefan ⛄ F. schrieb: > Wado: Schreibe mit bitte eine persönliche Nachricht, wenn du das Thema > ohne diese beiden Störenfriede fortsetzen möchtest. Du sitzt auf einem ganz schön hohen Ross. Es gibt überhaupt keinen Grund irgendjemanden hier als Störenfried zu bezeichnen. Geisterfahrer! Warum können die nicht alle mal in meiner Richtung fahren!
Wado: Schreibe mit bitte keine persönliche Nachricht, wenn du das Thema ohne diesen einen Störenfried fortsetzen möchtest. Ich vermute aber, dass Wado nicht mehr liest hier. So wie der Ursprungscode aussieht, ist er selbst mit einfachen C völlig überfordert. Aber Stefan kann das noch dazu hernehmen um Leute die nicht seiner Meinung sind als Störenfriede zu bezeichnen. So geht das, wenn man garnicht diskutieren will, sondern nur Recht haben will.
Stefan ⛄ F. schrieb: [Der Teil wurde eingefügt während ich meine Antwort schrieb] > Ich habe keine Lust mehr, an diesem albernen > Spielchen teilzunehmen. War da nicht ein Posting in dem Thread wo einer was von Fußaufstampfen geschrieben hat? Warst du das? Ist das jetzt deine Lösung nachdem du den Zitaten von dir nicht mehr auskommst? Ich glaub, man müsste mal einen Thread über Diskussionskultur aufmachen.
Stefan ⛄ F. schrieb: > Du kannst jetzt gerne zusammen mit MaWin noch weitere Lügen suchen wenn > du Spaß daran hast. Ich habe keine Lust mehr, an diesem albernen > Spielchen teilzunehmen. Diskussionskultur eines Kleinkindes.
Stefan ⛄ F. schrieb: > Schau mal aus dem Fenster - ein Vögelchen! Endlich mal wieder ein sinnvoller Beitrag von dir! Obwohl, Singvögel sind keine mehr da. Krähen und Raben schon. Das sind aber keine Vögelchen.
Schon lustig, Stefanus versucht hier ernsthaft zu helfen und son Müller schießt nur quer...
Mw E. schrieb: > Stefanus versucht hier ernsthaft zu helfen und son Müller > schießt nur quer... Die erste sinnvolle Antwort war von mir. Stefanus hat davor mit einer "Lösung" geantwortet die leider nur eine Hobbyisten-Lösung war. Du kannst darüber gerne diskutieren, lies aber den thread vorher komplett durch.
Schade dass es hier keinen break Befehl gibt, mit dem man diese Schleife unterbrechen kann.
Stefan ⛄ F. schrieb: > Schade dass es hier keinen break Befehl gibt, mit dem man diese Schleife > unterbrechen kann. Du könntest es mit exit() versuchen.
Nick M. schrieb: > Du könntest es mit exit() versuchen. Ich möchte nicht Wados Thread abbrechen, sondern nur diese alberne neben-Diskussion, die du hier zusammen mit Mawin antreibst. Hast du nicht besseres zu tun?
Stefan ⛄ F. schrieb: > Ich möchte nicht Wados Thread abbrechen, sondern nur diese alberne > neben-Diskussion, die du hier zusammen mit Mawin antreibst. Das ist ganz einfach: Antworte nicht mehr.
Stefan ⛄ F. schrieb: > Hast du nicht besseres zu tun? Eigentlich hast du Recht. Ich hab bisher auf eine vernünftige Antwort von dir gewartet. Statt dessen kommt jetzt nur noch Jammern. Ich wart mal ein wenig. So ganz hab ich die Hoffnung nicht aufgegeben.
MaWin schrieb: > Das ist ganz einfach: Antworte nicht mehr. Merkst du eigentlich nicht das Offensichtliche? Nick M. schrieb: > Ich wart mal ein wenig. So > ganz hab ich die Hoffnung nicht aufgegeben. Worauf wartest du, das ich dir Recht gebe? kannst du haben: Du hast Recht. Ich habe mir das Bild an die Wand gehängt, mit euren beiden Namen darunter.
Stefan ⛄ F. schrieb: > Ich habe mir das Bild an die Wand gehängt, mit euren beiden Namen > darunter. Es freut mich dann doch, dass du so klar zu erkennen gibst dass du keine Argumente hattest. Deinen Diskussionsthread hast du dann damit aber auch endgültig abgeschossen. Gratulation dazu!
Nick M. schrieb: > Es freut mich dann doch, dass du so klar zu erkennen gibst dass du keine > Argumente hattest. Ich hätte eher erkennen müssen, was hier vor sich geht. Das war mein eigentlicher Fehler.
Stefan ⛄ F. schrieb: > Worauf wartest du, das ich dir Recht gebe? kannst du haben: Du hast > Recht. Sicher hat er das. Wenn man den muellernick nimmt, der hat zwar ein Riesenklappe und ist fast so ein manischer Threadteilnehmer wie Du, aber man hat zumindest den Eindruck, dass er zu 80% weis wovon er schreibt. Den echten MaWin lassen wir mal aussen vor, der läuft zumindest für mich ausser Konkurrenz, wenn man mal Dein Gequake überhaupt als Konkurrenz betrachten mag. Kommen wir zu Dir: jedes arme Opfer, das bei 3 noch nicht auf dem Baum ist, wird von Dir wahllos zugequatscht, wobei die Richtigkeit oder Sinnhaftigkeit Deiner Beiträge gegen 10% geht. Du schwatzt einfach los nach dem Schrotgarbenprinzip = irgendwas wird schon treffen, respektive richtig sein. Solche Schwätzer tragen zum Sinken des Foren-IQ und zu dessen Unattraktivität m.E. deutlich mehr bei, als irgendein trollender Gastuser. Wenn ich mir mal vorstelle, da stellt ein naiver Forumsneuuser eine Frage ein und trifft gleich auf Dich, der Du schon auf Dein nächstes Opfer lauerst. Der bekommt doch 'nen Schaden für die Zukunft. Hat Dir denn irgendwer mal gesagt, dass weniger, aber gehaltvoller und vor allem "richtiger" letzten Endes besser ist, als Dein Dauergequake? Daher ist's auch kein Wunder, dass Du bei allen Deinen finanziellen Versuchen hier maximal erfolglos bist, denn wer will Dich den schon an der Backe? Nicht mal wenn ich Geld bekäme, möchte ich das.
Stefan ⛄ F. schrieb: > MWS, du kommst auch auf die Liste. In Zukunft wird es hier ruhiger > zugehen. Das wird für Dich dann zu ein Problem, wenn alle Dich auslachen, nur Du merkst es nicht weil Du die reale Welt ausgeblendet hast. Andererseits, so etwas hast Du ja jetzt schon.
Stefan ⛄ F. schrieb: > Ich hätte eher erkennen müssen, was hier vor sich geht. Das war mein > eigentlicher Fehler. Damit: nicht-mit-idioten-diskutieren.jpg hast du doch alles gesagt. Du brauchst keine Ausreden mehr, keine Entschuldigungen, keine Begründungen. Du hast dich damit ganz alleine als das bezeichnet was du bist. Und dafür danke ich dir!
MWS schrieb: > Das wird für Dich dann zu ein Problem, wenn alle Dich auslachen, nur Du > merkst es nicht weil Du die reale Welt ausgeblendet hast. Die Liste hilft mir dabei, mich nicht in sinnlose Diskussionen um meine Person verwickeln zu lassen. Auf die Idee hätte ich schon viel eher kommen sollen.
Stefan ⛄ F. schrieb: > MaWin schrieb: >> Das ist ganz einfach: Antworte nicht mehr. > Merkst du eigentlich nicht das Offensichtliche? Und du so? :)
Stefan ⛄ F. schrieb: > mich nicht in sinnlose Diskussionen um meine > Person verwickeln zu lassen. Keiner "verwickelt Dich", das machst Du schon selbst.
MWS schrieb: > Keiner "verwickelt Dich", das machst Du schon selbst. Wer weiß? Vielleicht steht seine Frau mit dem Nudelholz hinter ihm. So wie bei mir.
Ich glaube, ein Moderator kann jetzt den ganzen Müll ab 25.12.2020 22:50 löschen.
Stefan ⛄ F. schrieb: > Ich glaube, ein Moderator kann jetzt den ganzen Müll ab 25.12.2020 22:50 > löschen. Vielen Dank für diese äußerst wichtige Durchsage.
Stefan ⛄ F. schrieb: > Ich glaube, ein Moderator kann jetzt den ganzen Müll ab 25.12.2020 22:50 > löschen. Nein, ich bin schon dafür dass das alles so stehen bleibt. Vor allem das bereitwillig zur Verfügung gestellte Bildmaterial ist sehr wichtig für die Diskussion hier. Darum hier nochmal herzlichen Dank dafür. BTW: Die Löschwünsche vom Al.K. wurden zwar angenommen, nur das Ergebnis war "nicht ganz so" wie wohl gewünscht.
Es lohnt sich nicht, tagelang darüber zu streiten. Der TE mit den vielen Namen hat diesen Thread längst vergessen.