strcmp() aus musl libc

Mal generell gefragt warum nein? Alles war "unter" int ist, wird bei 
Berechnungen als int / unsigned int  betrachtet oder nicht?

Überleg dir, was bei Zeichen außerhalb des Bereichs 0-127 passiert.

zitter_ned_aso schrieb:
> return *(unsigned char *)l - *(unsigned char *)r;
> Wegen integer promotion wird doch die Subtraktion mit int's durchgeführt
> und dann das Ergebnis einem int-Rückgabewert zugewiesen. Also ist diese
> Typumwandlung an dieser Stelle gar nicht nötig.

nach langem Überlegen:

Integer promotion findet natürlich statt. Allerdings werden da falsche 
Zahlen zu Integer's befördert weil es bei den Buchstaben mit dem 
ASCII-Code > 127 einen Überlauf gibt (bei signed char). Und diese, 
falsche Zahl, wird nach "int" umgewandelt.

Bei mir funktioniert's übrigens auch wenn BEIDE Buchstaben >127 sind 
ohne explizite Typumwandlung.

1

return *l - *r;

Dann gibt es ja für beide einen Überlauf, aber der Abstand bleibt ja 
trotzdem gleich. Aber so ein Überlauf ist ja bei signed-Werten nicht 
definiert.Wenn es nur bei einem Buchstaben diesen Überlauf gibt, dann 
geht die Version ohne explizites Casten in die Hose.

Und dann habe ich noch eine Frage:
Warum wird die erste Variante akzeptiert und bei der zweiten - gewarnt?

1

 char str1[]="ü";                                                  

2

 char str2[]={'ü','\0'};

Carl D. schrieb:
> Z.B. "aaaa" vs. "ääää"

na dann bekomme ich ein falsches Ergebnis, habe ich doch oben 
geschrieben.


bei 'a' gibt es keine Überlauf, bei 'ä' schon.

zitter_ned_aso schrieb:
> Wenn es nur bei einem Buchstaben diesen Überlauf gibt, dann
> geht die Version ohne explizites Casten in die Hose.

Es gibt nirgendwo einen Überlauf.

Du hast ein 8-Bit-Muster und je nach Interpretation entspricht das 
-128..127 (signed char) oder 0..255 (unsgined char).  Die Erweiterung 
nach int ist in beiden Fällen eindeutig definiert und die folgende 
(int-)Subtraktion erfolgt ohne Überlauf, liefert aber je nach 
Interpretation unterschiedliche Ergebnisse.

ANSI-C verlangt bei strcmp (und auch bei memcmp) die 
unsigned-Interpretation.

Warum ist das kein Überlauf?

Ich kann das ja sogar nachbilden:

1

    int i=225;                                                          

2

    char ch=i; //Ueberlauf, da char==signed char                        

3

    int i_wrong = ch;                                                   

4

5

    printf("\ngegebener Integerwert: \t%d\n", i);                       

6

    printf("falscher Integerwert: \t%d\n", i_wrong);                    

7

    printf("Ueberlauf von  char: \t%d\n", ch);                          

8

    printf("auf uchar gecastet: \t%u\n", (unsigned char)ch);            

9

    printf("Ueberlauf berechnet: \t%d\n\n", (i%128)+(-128));

und die Ausgabe (bei mir):

1

gegebener Integerwert:  225

2

falscher Integerwert:   -31

3

Ueberlauf von  char:    -31

4

auf uchar gecastet:     225

5

Ueberlauf berechnet:    -31

> Warum ist das kein Überlauf?

Äppel und Birnen?  Du wandelst von int nach char, strcmp von char nach 
int.

Rolf M. schrieb:
> Übrigens gibt es in C per Definition keine Überläufe.

Quelle bitte.

leo

zitter_ned_aso schrieb:
> char str1[]="ü";
>  char str2[]={'ü','\0'};

so, als hex-Code geht's:

1

 char str2[]={'\xFC','\0'};

aber in der Console wird dann

1

<fc>

angezeigt. Im string werden die Zeichen aus dem erweiterten 
ASCII-Zeichensatz direkt akzeptiert, als einzelne char's jedoch nicht 
(egal ob signed/unsigned). Diese muss man dann codiert eingeben oder 
wchar nutzen.

Rolf M. schrieb:
> Zu unsigned Integern:

Du hattest nur diese gemeint oder auch signed integer? Bei letzteren 
gibt es sicher Overflow.

1

$ pdftotext c-std-n1256.pdf - | grep -c overflow

2

33

leo

Rolf M. schrieb:
> und ein Überlaufverhalten für
> signed-Integer nicht definiert ist.

Ja, haette ich genauer lesen muessen. Wie auch immer Overflow passiert 
;)

leo