Strings verbinden

[Wado U. (racole)]

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;
}

[MaWin (Gast)]

Arduino?
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Gruss Chregu

[MaWin (Gast)]

Wado U. schrieb:
> Und ja, ich möchte zwei Strings ohne die strcmp-Funktion vergleichen.

Warum?

[Stefan F. (Gast)]

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.

char a[201];
char b[100];

... (Eingabe) ...

strlcat(a, "&", sizeof(a));
strlcat(a, b, sizeof(a));

[Lukas S. (lukassugar)]

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)

}

[Stefan F. (Gast)]

Der Code ist furchtbar unleserlich.

[Nick M. (Gast)]

Wado U. schrieb:
> der die
> beiden durch ein & -Zeichen verbundenen Strings enthält, aber wie mache
> ich das?

snprintf lesen.

[Lukas S. (lukassugar)]

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)
}

[danke bitte (Gast)]

 [c]C-Code[/c]

[Nick M. (Gast)]

danke bitte schrieb:
>

C-Code

sowieso nicht lesenswert.

[bitte danke (Gast)]

strcpy(dest_str, name1);
strcat(dest_str, " & ");
strcat(dest_str, name2);

[bitte danke (Gast)]

Nick M. schrieb:
> danke bitte schrieb:
>>C-Code
> sowieso nicht lesenswert.

wow, die Recursion funktioniert hier sogar bei der Code-Formatierung.

[Jobst Q. (joquis)]

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;

[Nick M. (Gast)]

#define strBufferLen 200
char dest[strBufferLen];
snprintf(dest, strBufferLen, "%s&%s", "A", "B");


Ist schon jämmerlich hier!

[MaWin (Gast)]

MaWin schrieb:
> Gruss Chregu

Hat ja lange gedauert, bis sich einer der Psychopathen hier mal 
verplappert.

[pnp (Gast)]

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.

[can't see sharp (Gast)]

Jobst Q. schrieb:
> habe ich hier beschrieben:
>
> Beitrag "Re: strcpy mit automatischer Längenprüfung"

char* stpcpylim(char *t, const char *s,const char * lim){

lim--;
while(*s && t<lim) *t++=*s++;
 *t=0;
 return t;
 }

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?

  #define KEINE_AHNUNG 2000

   char* names[] = { "Alfred ",
                     "Else ",
                     "Rita ",
                     "Michael ",
                     "Fr. Suhrbier " };

   char dest[128] = "";

   char* p =
      stpcpylim (dest, names[0], dest + KEINE_AHNUNG);

   for (size_t i = 1; i < 5; i++) {
      p = stpcpylim (p, names[i], p + KEINE_AHNUNG);
   }

   puts (dest);

[Stefan F. (Gast)]

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.

[Nick M. (Gast)]

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.

[MaWin (Gast)]

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?

[Stefan F. (Gast)]

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.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

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.

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
> Ich habe nur strlcat() von BSD benutzt

Das strlcat ist bestimmt erheblich langsamer, weil es mindestens einmal 
strlen() aufrufen muss.

[Mark B. (markbrandis)]

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

[Mark B. (markbrandis)]

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.

[Nick M. (Gast)]

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.

[MaWin (Gast)]

Nick M. schrieb:
> Damit ist also der Beitrag wertlos.

Damit ist also dein Beitrag wertlos.

[Jobst Q. (joquis)]

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.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

Hier ist der Beweis:

stefan@stefanpc:~/Downloads$ gcc test1.c
stefan@stefanpc:~/Downloads$ time ./a.out 
Herr von Ribbek auf Ribbek&im Havelland

real  0m0,563s
user  0m0,563s
sys  0m0,000s

stefan@stefanpc:~/Downloads$ gcc test2.c
stefan@stefanpc:~/Downloads$ time ./a.out 
Herr von Ribbek auf Ribbek&im Havelland

real  0m0,727s
user  0m0,723s
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?

[MaWin (Gast)]

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?

[MaWin (Gast)]

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

[Stefan F. (Gast)]

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

[Stefan F. (Gast)]

Bei kürzeren Strings wird der Unterschied übrigens größer:

stefan@stefanpc:~/Downloads$ gcc test1.c
stefan@stefanpc:~/Downloads$ time ./a.out 
A&B

real  0m0,249s
user  0m0,250s
sys  0m0,000s

stefan@stefanpc:~/Downloads$ gcc test2.c
stefan@stefanpc:~/Downloads$ time ./a.out 
A&B

real  0m0,680s
user  0m0,676s
sys  0m0,004s

[pnp (Gast)]

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

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

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!

[Jobst Q. (joquis)]

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.

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

Ist gut, dein Vorschlag ist der einzig sinnvolle. Alle anderen sind
> jämmerlich
wie du sagst. Und jetzt geh wieder spielen.

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
> Und jetzt geh wieder spielen.

Ich spiele nicht, im Gegensatz zu dir und machen Anderen hier.

[can't see sharp (Gast)]

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

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

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"

[Nick M. (Gast)]

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?

[Stefan F. (Gast)]

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.

[Jobst Q. (joquis)]

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.

[MaWin (Gast)]

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.

[Jobst Q. (joquis)]

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?

[Nick M. (Gast)]

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

[can't see sharp (Gast)]

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

[Stefan F. (Gast)]

MaWin schrieb:
> Treffer und versenkt.

Ja, geil was?

Was für ein Niveau! Noch tiefer geht es nicht mehr.

[Nick M. (Gast)]

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);

[Nick M. (Gast)]

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!

[Stefan F. (Gast)]

Nick M. schrieb:
> strncpy(destStr, "A", buffSize);

Jetzt fehlt nur noch, dass zu zum Anhängen weiterer Zeichenketten 
strlcat() empfiehlst.

SCNR

[Stefan F. (Gast)]

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.

[MaWin (Gast)]

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.

[Nick M. (Gast)]

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.

[Jobst Q. (joquis)]

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.

[Rolf M. (rmagnus)]

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.

[Nick M. (Gast)]

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.

[Jobst Q. (joquis)]

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.

[MaWin (Gast)]

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.

[Nick M. (Gast)]

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.

[Jobst Q. (joquis)]

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.

[Nick M. (Gast)]

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

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

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.

[Rolf M. (rmagnus)]

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.

[Jobst Q. (joquis)]

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.

[Rolf M. (rmagnus)]

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.

[MaWin (Gast)]

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.

[Jobst Q. (joquis)]

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.

[Rolf M. (rmagnus)]

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.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

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.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

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.

[MaWin (Gast)]

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.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

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.

[Jobst Q. (joquis)]

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.

[Stefan F. (Gast)]

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.

[Nick M. (Gast)]

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.

[Nick M. (Gast)]

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.

[MaWin (Gast)]

Jobst Q. schrieb:
> Bei der elektrischen Absicherung von Steckdosen stört es mich auch nicht,

Äpfel und Birnen.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

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.

[Nick M. (Gast)]

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

[Stefan F. (Gast)]

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.

[Nick M. (Gast)]

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?

[MaWin (Gast)]

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 (Gast)]

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!

[Stefan F. (Gast)]

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.

[Stefan F. (Gast)]

Wado: Schreibe mit bitte eine persönliche Nachricht, wenn du das Thema 
ohne diese beiden Störenfriede fortsetzen möchtest.

[Nick M. (Gast)]

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.

[MaWin (Gast)]

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!

[Nick M. (Gast)]

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.

[Nick M. (Gast)]

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. (Gast)]

Schau mal aus dem Fenster - ein Vögelchen!

[MaWin (Gast)]

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.

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

Aha

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Schon lustig, Stefanus versucht hier ernsthaft zu helfen und son Müller 
schießt nur quer...

[MaWin (Gast)]

Mw E. schrieb:
> Stefanus versucht hier ernsthaft zu helfen

Richtig. Mit Betonung auf versucht.

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

Schade dass es hier keinen break Befehl gibt, mit dem man diese Schleife 
unterbrechen kann.

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

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?

[MaWin (Gast)]

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.

[Nick M. (Gast)]

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.

[Stefan F. (Gast)]

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.

[Nick M. (Gast)]

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!

[Stefan F. (Gast)]

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.

[MWS (Gast)]

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. (Gast)]

MWS, du kommst auch auf die Liste. In Zukunft wird es hier ruhiger 
zugehen.

[MWS (Gast)]

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.

[Nick M. (Gast)]

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!

[Stefan F. (Gast)]

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.

[MaWin (Gast)]

Stefan ⛄ F. schrieb:
> MaWin schrieb:
>> Das ist ganz einfach: Antworte nicht mehr.
> Merkst du eigentlich nicht das Offensichtliche?

Und du so? :)

[MWS (Gast)]

Stefan ⛄ F. schrieb:
> mich nicht in sinnlose Diskussionen um meine
> Person verwickeln zu lassen.

Keiner "verwickelt Dich", das machst Du schon selbst.

[MaWin (Gast)]

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.

[Stefan F. (Gast)]

Ich glaube, ein Moderator kann jetzt den ganzen Müll ab 25.12.2020 22:50
löschen.

[MaWin (Gast)]

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.

[Nick M. (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

Es lohnt sich nicht, tagelang darüber zu streiten. Der TE mit den vielen
Namen hat diesen Thread längst vergessen.