Discussion:
Mal noch ein anderer Ueberlaufsgedankengang
(zu alt für eine Antwort)
Rainer Weikusat
2018-09-24 18:44:51 UTC
Permalink
Angenommen folgendes,

signed char c;

c = SCHAR_MAX;
c = c + 1;

Wegen der sogenannten "Ganzahlbefoerderungen" (integer promotions) und
der fuer die Addition verlangten Anwendung der "ueblichen, arithmetische
Konvertierungen" (6.5.6|4) wird die linke Seite dieser Anweisung als Typ
int ausgerechnet, es gibt also nicht nur in darstellbares Resultat (wenn
INT_MAX > CHAR_MAX gilt) sondern ausserdem keinen Ueberlauf.

Die Zuweisung weist also einen int-Wert einem char-Objekt zu. 6.5.16|2
verlangt, dass dieser int-Wert nach char konvertiert wird. Die Semantik
von Konvertierungen, die im Zusammenhang mit Operatoren vorgenommen
werden, wird durch Abschnitt 6.3 beschrieben und der fuer den gegebenen
Fall anwendbare Teil davon ist (unueberaschenderweise) 6.3.1.3|3,

Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.

Dh die Annahme mit dem "nichtdarstellbaren Wert" den eine Addition noch
irgendmandes Meinung haben sollte, obwohl sie den nicht hat, kann nur
auf Typen zutreffen, deren Groesse groesser oder gleich der Groesse von
int ist.

Die C-Norm wuerde hier also *falls* eine Implementierung
Ganzahltypen hat, die kleiner als int sind, implementierungsabhaengiges
Verhalten fordern und fuer andere angeblich kein Verhalten definieren
waehrend das Verhalten fuer Implementierungen, bei denen int der
kleinste Typ ist, immer undefiniert waere, oder, kuerzer: Ob
Ganzahlueberlauf undefiniertes Verhalten hat ist durch die C-Norm selber
undefiniert. Meta-undefiniertes Verhalten!

Die gcc-Norm sieht das halt anders aber nu ja ...
Juergen Ilse
2018-09-24 19:36:15 UTC
Permalink
Hallo,
Post by Rainer Weikusat
Angenommen folgendes,
signed char c;
c = SCHAR_MAX;
c = c + 1;
Wegen der sogenannten "Ganzahlbefoerderungen" (integer promotions) und
der fuer die Addition verlangten Anwendung der "ueblichen, arithmetische
Konvertierungen" (6.5.6|4) wird die linke Seite dieser Anweisung als Typ
int ausgerechnet, es gibt also nicht nur in darstellbares Resultat (wenn
INT_MAX > CHAR_MAX gilt) sondern ausserdem keinen Ueberlauf.
Die Zuweisung weist also einen int-Wert einem char-Objekt zu. 6.5.16|2
verlangt, dass dieser int-Wert nach char konvertiert wird. Die Semantik
von Konvertierungen, die im Zusammenhang mit Operatoren vorgenommen
werden, wird durch Abschnitt 6.3 beschrieben und der fuer den gegebenen
Fall anwendbare Teil davon ist (unueberaschenderweise) 6.3.1.3|3,
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Stimmt. Du hast dir hier genau einen Fall herausgepickt, bei dem der
Standard nicht "undefined" sondern "implementation defined" sagt.
Wie sieht es aus, wenn du das mit signed int statt signed char machst?
Da hast du keine integer promotion auf einen "hinreichend grossen Typ",
dafuer aber einen overflow bei der Addition ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Rainer Weikusat
2018-09-24 20:12:37 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Rainer Weikusat
Angenommen folgendes,
signed char c;
c = SCHAR_MAX;
c = c + 1;
Wegen der sogenannten "Ganzahlbefoerderungen" (integer promotions) und
der fuer die Addition verlangten Anwendung der "ueblichen, arithmetische
Konvertierungen" (6.5.6|4) wird die linke Seite dieser Anweisung als Typ
int ausgerechnet, es gibt also nicht nur in darstellbares Resultat (wenn
INT_MAX > CHAR_MAX gilt) sondern ausserdem keinen Ueberlauf.
Die Zuweisung weist also einen int-Wert einem char-Objekt zu. 6.5.16|2
verlangt, dass dieser int-Wert nach char konvertiert wird. Die Semantik
von Konvertierungen, die im Zusammenhang mit Operatoren vorgenommen
werden, wird durch Abschnitt 6.3 beschrieben und der fuer den gegebenen
Fall anwendbare Teil davon ist (unueberaschenderweise) 6.3.1.3|3,
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Stimmt. Du hast dir hier genau einen Fall herausgepickt, bei dem der
Standard nicht "undefined" sondern "implementation defined" sagt.
Und zwar als Beispiel fuer den folgenden Text, der oben fehlt und sich
genau zu den Dingen aeussert, zu denen Du ebenfalls eine Absatz
geschrieben hattest, lediglich einen mit einer anderen Tendenz, deswegen
hier nochmal in Kuerze: Folgt man der "unrepraesentierbarer Wert bei
Ganzzahladdition"-Annahme, dann endet bei unerklaerlichen oder
wenigstens unerklaerten Inkonsistenzen im Normtext. Dh selbst wenn man
von allem, was sonst noch gegen diese Annahme spricht, absieht (wie die
willkuerliche Annahme einer bestimmten Definition von "Addition" die
technisch nicht realisoert werden kann) ist das Ergebnis immer noch
wirres Zeug.

Hier muss man allmaehlich an einen gcc-Fuenfjaehrigen denken, der, mit dem
Fuesschen aufstampfend, in ein heulendes "Ich will aber!"-Crescendo
ausbricht ...
Helmut Schellong
2018-09-24 20:11:33 UTC
Permalink
Post by Rainer Weikusat
[...]
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Dh die Annahme mit dem "nichtdarstellbaren Wert" den eine Addition noch
irgendmandes Meinung haben sollte, obwohl sie den nicht hat, kann nur
auf Typen zutreffen, deren Groesse groesser oder gleich der Groesse von
int ist.
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.

{clang hat die Option -fwrapv ebenfalls.}
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2018-09-24 20:35:21 UTC
Permalink
Hallo,
Post by Helmut Schellong
Post by Rainer Weikusat
[...]
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Dh die Annahme mit dem "nichtdarstellbaren Wert" den eine Addition noch
irgendmandes Meinung haben sollte, obwohl sie den nicht hat, kann nur
auf Typen zutreffen, deren Groesse groesser oder gleich der Groesse von
int ist.
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.
Ein Compiler, der integer promotions auf "groessere Typen" durchfuehrt,
ohne dass mindestens einer der Operanden diesen groesseren Typ hat oder
aber mindestens einer der Operanden einen Typ "kleiner int" hat, ent-
spricht nicht dem Standard.
Post by Helmut Schellong
{clang hat die Option -fwrapv ebenfalls.}
Das Verhalten bei "integer overflow" zu definieren (was damit ja geschieht)
ist eine Erweiterung des Standards. Der Standard schreibt da kein definiertes
Verhalten vor.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Schellong
2018-09-24 21:01:34 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Helmut Schellong
Post by Rainer Weikusat
[...]
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Dh die Annahme mit dem "nichtdarstellbaren Wert" den eine Addition noch
irgendmandes Meinung haben sollte, obwohl sie den nicht hat, kann nur
auf Typen zutreffen, deren Groesse groesser oder gleich der Groesse von
int ist.
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.
Ein Compiler, der integer promotions auf "groessere Typen" durchfuehrt,
ohne dass mindestens einer der Operanden diesen groesseren Typ hat oder
aber mindestens einer der Operanden einen Typ "kleiner int" hat, ent-
spricht nicht dem Standard.
c = (long long)inta + intb - intk;
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2018-09-25 02:48:35 UTC
Permalink
Hallo,
Post by Helmut Schellong
Post by Juergen Ilse
Post by Helmut Schellong
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.
Ein Compiler, der integer promotions auf "groessere Typen" durchfuehrt,
ohne dass mindestens einer der Operanden diesen groesseren Typ hat oder
aber mindestens einer der Operanden einen Typ "kleiner int" hat, ent-
spricht nicht dem Standard.
c = (long long)inta + intb - intk;
"Integer promotions" == "implizite Konvertierung auf eine ngroesseren Typ".
Was du hier machst, ist eine explizite Konvertierung, und dadurch die Er-
zeugung von integer promotion aufgrund von Arithmetik mit einem Operand
eines groesseren Typs, was ich da oben auch explizit erwaehnt habe. Nur
darum ging es hier ueberhaupt nicht.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Schellong
2018-09-25 13:00:29 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Helmut Schellong
Post by Juergen Ilse
Post by Helmut Schellong
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.
Ein Compiler, der integer promotions auf "groessere Typen" durchfuehrt,
ohne dass mindestens einer der Operanden diesen groesseren Typ hat oder
aber mindestens einer der Operanden einen Typ "kleiner int" hat, ent-
spricht nicht dem Standard.
c = (long long)inta + intb - intk;
"Integer promotions" == "implizite Konvertierung auf eine ngroesseren Typ".
Was du hier machst, ist eine explizite Konvertierung, und dadurch die Er-
zeugung von integer promotion aufgrund von Arithmetik mit einem Operand
eines groesseren Typs, was ich da oben auch explizit erwaehnt habe. Nur
darum ging es hier ueberhaupt nicht.
Natürlich mache ich hier eine explizite Konvertierung.
Das habe ich oben durch 'auf (long long) gew' auch angezeigt.

Diese Konvertierung löst das von Rainer W. mitgeteilte Problem, daß
ab int-Größe keine int-Promotion mehr stattfindet.
Dann macht man eben eine explizite long-long-Promotion.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2018-09-25 13:11:55 UTC
Permalink
Hallo,
Post by Helmut Schellong
Post by Juergen Ilse
Post by Helmut Schellong
c = (long long)inta + intb - intk;
"Integer promotions" == "implizite Konvertierung auf eine ngroesseren Typ".
Was du hier machst, ist eine explizite Konvertierung, und dadurch die Er-
zeugung von integer promotion aufgrund von Arithmetik mit einem Operand
eines groesseren Typs, was ich da oben auch explizit erwaehnt habe. Nur
darum ging es hier ueberhaupt nicht.
Natürlich mache ich hier eine explizite Konvertierung.
Das habe ich oben durch 'auf (long long) gew' auch angezeigt.
Nur: Darum ging es hier ueberhaupt nicht.
Post by Helmut Schellong
Diese Konvertierung löst das von Rainer W. mitgeteilte Problem, daß
ab int-Größe keine int-Promotion mehr stattfindet.
Dann macht man eben eine explizite long-long-Promotion.
... und verschiebt das *exakt* *selbe* Problem damit nur vom Typ int auf
den Typ long long ... Das Problem als solches bleibt doch nach wie vor
bestehen. Auch wenn du es von einem Ganzzahltyp auf den naechsten schiebst:
da es nicht unendlich viele Ganzzahltypen oder einen Ganzzahltyp mit un-
beschraenktem Wertebereich in C gibt, schiebst du damit das Problem nur
vor dir her aber loest es nicht.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Schellong
2018-09-25 13:34:08 UTC
Permalink
Post by Juergen Ilse
Post by Helmut Schellong
Diese Konvertierung löst das von Rainer W. mitgeteilte Problem, daß
ab int-Größe keine int-Promotion mehr stattfindet.
Dann macht man eben eine explizite long-long-Promotion.
... und verschiebt das *exakt* *selbe* Problem damit nur vom Typ int auf
den Typ long long ... Das Problem als solches bleibt doch nach wie vor
da es nicht unendlich viele Ganzzahltypen oder einen Ganzzahltyp mit un-
beschraenktem Wertebereich in C gibt, schiebst du damit das Problem nur
vor dir her aber loest es nicht.
Das stimmt prinzipiell.
Allerdings ist der Zahlenbereich von long long so immens groß, daß
zumindest ich damit kaum jemals in Schwulitäten gerate.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2018-09-25 14:49:22 UTC
Permalink
Hallo,
Post by Helmut Schellong
Post by Juergen Ilse
Post by Helmut Schellong
Diese Konvertierung löst das von Rainer W. mitgeteilte Problem, daß
ab int-Größe keine int-Promotion mehr stattfindet.
Dann macht man eben eine explizite long-long-Promotion.
... und verschiebt das *exakt* *selbe* Problem damit nur vom Typ int auf
den Typ long long ... Das Problem als solches bleibt doch nach wie vor
da es nicht unendlich viele Ganzzahltypen oder einen Ganzzahltyp mit un-
beschraenktem Wertebereich in C gibt, schiebst du damit das Problem nur
vor dir her aber loest es nicht.
Das stimmt prinzipiell.
Allerdings ist der Zahlenbereich von long long so immens groß, daß
zumindest ich damit kaum jemals in Schwulitäten gerate.
Klingt ein bischen nach "Mehr als 640 Kilobyte Speicher braucht kein
Mensch“ ... Entweder man loest das Problem oder man akzeptiert das Problem
und aendert sein Programme so ab, dass das Problem abgefangen wird *bevor*
es auftritt. Alles andere waere Gluecksspiel (auch wenn es in vielen Faellen
eben eine sehr grosse Chance auf "Glueck" gibt).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Schellong
2018-09-25 15:57:05 UTC
Permalink
Post by Juergen Ilse
Post by Helmut Schellong
Das stimmt prinzipiell.
Allerdings ist der Zahlenbereich von long long so immens groß, daß
zumindest ich damit kaum jemals in Schwulitäten gerate.
Klingt ein bischen nach "Mehr als 640 Kilobyte Speicher braucht kein
Mensch“ ... Entweder man loest das Problem oder man akzeptiert das Problem
und aendert sein Programme so ab, dass das Problem abgefangen wird *bevor*
es auftritt. Alles andere waere Gluecksspiel (auch wenn es in vielen Faellen
eben eine sehr grosse Chance auf "Glueck" gibt).
Ich löse solche Probleme in 100% aller Fälle.
Indem ich weiß, wie groß Werte maximal werden können, löst
bereits den weitaus größten Anteil dieser Probleme.

Beispiel: Der Exit-Code von Kommandos (in bish).
Das ist int Exit; mit Werten von 0..127 - garantiert.
Der User kann per false n; mehr angeben - aber es bleibt int.

Beispiel: Meßwerte.
Die Meßwerte betragen maximal 320 Volt.
Folglich reichen -32767 .. +32767 aus, für hundertstel Volt.
Dafür reicht ein short auf Mikrokontroller.
Der AD-Wandler gibt 4095 als maximalen Wert aus.
Mittelwerte werden über einen long-Typ errechnet;
es werden darin maximal 48 short-Werte aufaddiert.

...
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2018-09-25 19:01:50 UTC
Permalink
Post by Juergen Ilse
... und verschiebt das *exakt* *selbe* Problem damit nur vom Typ int auf
den Typ long long ... Das Problem als solches bleibt doch nach wie vor
da es nicht unendlich viele Ganzzahltypen oder einen Ganzzahltyp mit un-
beschraenktem Wertebereich in C gibt, schiebst du damit das Problem nur
vor dir her aber loest es nicht.
Prinzipiell könnte man natürlich gmp (oder eine andere bigint
Library) verwenden. Dann verschiebt man das Problem allerdings
in Richtung lange Laufzeiten und eventuell sehr großen
Speicherbedarf...
Thomas Koenig
2018-09-25 18:52:26 UTC
Permalink
Post by Helmut Schellong
Natürlich mache ich hier eine explizite Konvertierung.
Das habe ich oben durch 'auf (long long) gew' auch angezeigt.
Der Thread bezog sich mal auf C89, da gab es noch kein long long.

Was machst du denn bei der Addition von zwei "long long" Zahlen,
wenn kein größerer Datentyp mehr zur Verfügung steht?
Helmut Schellong
2018-09-25 19:45:03 UTC
Permalink
Post by Thomas Koenig
Post by Helmut Schellong
Natürlich mache ich hier eine explizite Konvertierung.
Das habe ich oben durch 'auf (long long) gew' auch angezeigt.
Der Thread bezog sich mal auf C89, da gab es noch kein long long.
Nein, dieser Thread wurde gestern von Rainer W. gestartet.

gcc konnte schon lange zuvor long long, auch durch Kaskadierung.
Post by Thomas Koenig
Was machst du denn bei der Addition von zwei "long long" Zahlen,
wenn kein größerer Datentyp mehr zur Verfügung steht?
Daß bei dem Zahlenbereich von long long eine zu große Summe
entsteht, ist sehr unwahrscheinlich.
Es sei denn, ich will absichtlich über die Limits wrappen.

Ich habe hierzu schon eine Antwort an J. Ilse gegeben.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
J***@fokus.fraunhofer.de
2018-10-06 22:18:18 UTC
Permalink
Post by Juergen Ilse
Das Verhalten bei "integer overflow" zu definieren (was damit ja geschieht)
ist eine Erweiterung des Standards. Der Standard schreibt da kein definiertes
Verhalten vor.
Der C Standard tut das nicht, der POSIX Standard aber sehr wohl.
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Rainer Weikusat
2018-09-24 21:10:53 UTC
Permalink
Post by Helmut Schellong
Post by Rainer Weikusat
[...]
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Dh die Annahme mit dem "nichtdarstellbaren Wert" den eine Addition noch
irgendmandes Meinung haben sollte, obwohl sie den nicht hat, kann nur
auf Typen zutreffen, deren Groesse groesser oder gleich der Groesse von
int ist.
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.
Sicher kann das so gemacht werden. Andererseits ist die Annahme, eine
Maschinenaddition koenne oder solle in hypothetisches "nicht
darstellbares Resultat" haben, weil des jemanden zufaellig in den Kram
passt, ohnehin Quatsch. Aber um etwas real existierendes geht es in
dieser Diskussion ohnehin nicht und obiger Beitrag sollte bloss
aufzeigen, dass die zugrundeliegenden Annahmen noch nicht mal mit sich
selber konsistent sind, weil vorzeichenbehaftete Ganzahlen ohne
technische Begruendung in zwei Gruppen aufgeteilt werden.
Thomas Koenig
2018-09-25 06:39:15 UTC
Permalink
Post by Rainer Weikusat
Andererseits ist die Annahme, eine
Maschinenaddition koenne oder solle in hypothetisches "nicht
darstellbares Resultat" haben, weil des jemanden zufaellig in den Kram
passt, ohnehin Quatsch.
Sicher? IIRC hat zSystem Hardware-Support für packed decimal,
und da gibt es sogar Integer-NaNs.

Ich gebe aber zu, dass so ein Datentyp schlecht in C reinpasst :-)
Helmut Schellong
2018-09-25 13:28:21 UTC
Permalink
Post by Thomas Koenig
Post by Rainer Weikusat
Andererseits ist die Annahme, eine
Maschinenaddition koenne oder solle in hypothetisches "nicht
darstellbares Resultat" haben, weil des jemanden zufaellig in den Kram
passt, ohnehin Quatsch.
Sicher? IIRC hat zSystem Hardware-Support für packed decimal,
und da gibt es sogar Integer-NaNs.
Ich gebe aber zu, dass so ein Datentyp schlecht in C reinpasst :-)
Paßt da gar nicht rein.

Der iX87 konnte schon immer 18-stelliges gepacktes BCD.
Also die Ziffern 0..9 in einem Nibble.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Rainer Weikusat
2018-09-25 17:42:29 UTC
Permalink
Post by Thomas Koenig
Post by Rainer Weikusat
Andererseits ist die Annahme, eine
Maschinenaddition koenne oder solle in hypothetisches "nicht
darstellbares Resultat" haben, weil des jemanden zufaellig in den Kram
passt, ohnehin Quatsch.
Sicher? IIRC hat zSystem Hardware-Support für packed decimal,
und da gibt es sogar Integer-NaNs.
Die wird man durch Addition aber kaum erzeugen koennen.
Post by Thomas Koenig
Ich gebe aber zu, dass so ein Datentyp schlecht in C reinpasst :-)
Das ausserdem: Eine C-Ganzahl besteht as n Wertbits und einem
Vorzeichenbit. Falls man zu einer vorzeichenbehafteten Zahl, bei der
alle Wertbits gesetzt sind, 1 addiert, koennte das als Fehler behandelt
werden, dh eine Ausnahme ausloesen oder es ergibt sich eine mit n
Wertbits darstellbare Zahl. Was sich nicht ergibt, ist, das die CPU mal
kurz aus sich heraustritt, aufgrund von theoretischen Ueberlegungen
ueber unendliche Zahlenmengen ein magisches, n+1 Wertbit temporaer
herbeizaubert und mit Hilfe dessen feststellt, das die Addition ein
nicht repraesentierbares Ergebnis haette haben sollen.

Zu so einer Ueberlegung ist hoechstebs ein Mensch faehig, der eine
bestimmte Vortstellung von Addition hat wie zB "trotzdem ich mit einer
endlichen Menge darstellbarer Zahlen hantiere, moechte ich so tun, als
ob eine unendliche Menge darstellbarer Zahlen stattdessen vorhanden
waere".
Thomas Koenig
2018-09-25 19:22:30 UTC
Permalink
Post by Rainer Weikusat
Post by Thomas Koenig
Post by Rainer Weikusat
Andererseits ist die Annahme, eine
Maschinenaddition koenne oder solle in hypothetisches "nicht
darstellbares Resultat" haben, weil des jemanden zufaellig in den Kram
passt, ohnehin Quatsch.
Sicher? IIRC hat zSystem Hardware-Support für packed decimal,
und da gibt es sogar Integer-NaNs.
Korrektur: Ich habe nochmal danach gesucht, und es könnte sein,
dass ich das mit den "decimal floats" verwechselt habe. Die gibt
es auf den IBM-Mainframes.
Post by Rainer Weikusat
Die wird man durch Addition aber kaum erzeugen koennen.
Ich würde mir schon manchmal ein NaN für Integer wünschen.
Für floats kann nan NaN als "hier sind wirklich keine Daten"
(miss)brauchen, für ints gibt es sowas halt nicht. Und
wenn man sich einen speziellen Wert raussucht, dann wird
der bestimmt in den normalen Daten auftauchen :-|
G. B.
2018-10-01 16:15:27 UTC
Permalink
Post by Thomas Koenig
Und
wenn man sich einen speziellen Wert raussucht, dann wird
der bestimmt in den normalen Daten auftauchen :-|
Ein guter Grund die vordefinierten Ganzzahl-Typen nur für versteckte
Datenrepräsentation zu benutzen. Das ermöglicht dünne Schnittstellen mit
unzweifelhaften Typen, nimmt andererseits Spielraum für interessante
Dispute zur fallweise korrekten Verwendung von int und seiner Portabilität.
Thomas Koenig
2018-10-01 16:53:12 UTC
Permalink
Post by G. B.
Post by Thomas Koenig
Und
wenn man sich einen speziellen Wert raussucht, dann wird
der bestimmt in den normalen Daten auftauchen :-|
Ein guter Grund die vordefinierten Ganzzahl-Typen nur für versteckte
Datenrepräsentation zu benutzen.
Versteckt vor wem? Wie?
Post by G. B.
Das ermöglicht dünne Schnittstellen
Was macht eine dünne Schnittstelle aus? Was wäre im Gegensatz
dazu eine dicke Schnittstelle?
Post by G. B.
mit
unzweifelhaften Typen,
Was ist ein unzweifelhafter Typ? Wie unterscheidet er sich von einem
zweifelhaften Typ?
Post by G. B.
nimmt andererseits Spielraum für interessante
Dispute zur fallweise korrekten Verwendung von int und seiner Portabilität.
Da ich die eine Seite nicht verstanden habe, verstehe ich die
andere auch nicht so recht.
Stefan Ram
2018-10-01 17:28:27 UTC
Permalink
Post by Thomas Koenig
Versteckt vor wem? Wie?
Ich denke das geht in die Richtung von "private" (C++,
Java).

Wenn man eine Funktion einer Schnittstelle eines Objektes
wie

set_price( object, double )

verwendet, scheint im Prinzip durch, daß das Objekt
wahrscheinlich ein internes Feld "price" vom Typ »double« hat.

Man kann das interne Feld dann später nur noch beschränkt
von »double« auf »decimal« ändern (wenn es das in einem
zukünftigen C einmal geben sollte).

Eventuelle Rundungsfehler per »double« bleiben in der
Schnittstelle, da diese »double« enthält, selbst wenn
man den Typ des Feldes auf »decimal« geändert hat.

Daher habe ich mir einmal überlegt, daß in Schnittstellen
eigentlich nur ein Zeichenfolgentyp verwendet werden sollte.
Nur dann ist der interne Typ wirklich gut versteckt und
kann wirkungsvoll geändert werden, ohne daß die Schnittstelle
geändert werden muß! Am besten gleich mit UTF-8.

set_price( object, "1.23" );

Im Grund hat man so etwas dann bei SQL oder Webservices:
Die ganze Kommunikation erfolgt im Grunde über Zeichenfolgen.

Dabei ist das Serialisieren und Deserialisieren eigentlich
sehr ineffizient.
G.B.
2018-10-01 20:36:51 UTC
Permalink
Post by Thomas Koenig
Was ist ein unzweifelhafter Typ? Wie unterscheidet er sich von einem
zweifelhaften Typ?
Die folgenden Definitionen sind aus der Hüfte geschossen und
hier nur für ein vollständiges Beispiel versammelt.

Ziel ist, komische Summen durch Schnittstellenbildung zu
unterbinden. Z.B. ist "+" für union V unten nicht definiert.
Mit derartigen Schnittstellen muss man sich mehr anstrengen,
um was kaputt zu rechnen. Implementierungen der Schnittstelle
können aber Aspekte z.B. der Wertebereiche "privat" halten,
so dass Annahmen darüber weniger wahrscheinlich sind, als
wenn "öffentlich" mit int-Objekten gerechnet werden kann. Vgl.
die #define-Zeilen im body file, das eher als "privat"
erachtet ist.

Leider können die Typen nicht leicht privat gemacht werden (vgl.
Beitrag von Stefan Ram). Immerhin aber obskur, ohne Verlust
für die "öffentliche" Schnittstelle. Der Idee nach entspricht
in union V:
.f1 einer Kodierung eines Fehlers und ist tatsächlich vom
Typ enum Grund;
.f2 dem den Wert tragenden Mitglied.

typedef int Boolesch;

enum Grund {
zuKlein = -102,
zuGroß = -101
};

union V { /* SOLL: Felder uninteressant (versteckt) */
int f1;
int f2;
};


Boolesch ist_ok(union V);
union V lese_v(int);
int gebe_zahl(union V);
union V f(union V);
union V g(union V);
union V summe(union V, union V);

/* -8<- */

#include <stdlib.h>
#include <stdio.h>
#include "iface.h"

int main(int argc, char* argv[]) {
union V k;

k = lese_v(strtol(argv[argc-1], NULL, 10));
if (ist_ok(k)) {
k = summe(f(k), g(k));
}
return printf("%d\n", ist_ok(k) ? gebe_zahl(k) : -1);
}

/* -8<- */

#include "iface.h"

#define min_V 0
#define max_V 10000

union V f(union V x) {
return (union V) { .f2 =x.f2 / 2 };
}

union V g(union V x) {
register int v = x.f2;
return (union V) {
.f2 = v < max_V ? v + 1 : v
};
}

int gebe_zahl(union V x) {
return x.f2;
}

Boolesch ist_ok(union V datum) {
switch (datum.f1) {
case zuKlein: return 0;
case zuGroß: return 0;
}
return 1;
}

union V lese_v(int gelesen) {
if (gelesen < min_V) {
return (union V) { .f1 = zuKlein };
}
if (gelesen > max_V) {
return (union V) { .f1 = zuGroß };
}
return (union V) { .f2 = gelesen };
}

union V summe(union V L, union V R) {
register long v = L.f2 + R.f2;

return (v > max_V) ? (union V) {
.f1 = zuGroß
} : (union V) {
.f2 = v
};
}
G.B.
2018-10-01 20:37:00 UTC
Permalink
Post by Thomas Koenig
Post by G. B.
Post by Thomas Koenig
Und
wenn man sich einen speziellen Wert raussucht, dann wird
der bestimmt in den normalen Daten auftauchen :-|
Ein guter Grund die vordefinierten Ganzzahl-Typen nur für versteckte
Datenrepräsentation zu benutzen.
Versteckt vor wem? Wie?
Versteckt i.S.d. Schnittstelle vor denjenigen, die in Typen
hinein interpretieren, was zwar formal korrekt ist,
nicht aber aus der Sicht der Anwendungslogik korrekt.
Zum Beispiel den freien Umgang mit speziellen Werten.
Post by Thomas Koenig
Post by G. B.
Das ermöglicht dünne Schnittstellen
Was macht eine dünne Schnittstelle aus? Was wäre im Gegensatz
dazu eine dicke Schnittstelle?
Eine dünne Schnittstelle versucht nicht, den Detailgrad
des ursprünglichen Gegebenen zu verringern, sondern
passt die gegebene Struktur nur in die eigenen Vorstellungen
oder in die für vorteilhaft erachteten Konventionen ein.
Beispiel mit einem speziellem int-Wert -1 und Summe, wo
eine Schnittstelle fehlt:

/* Vorgabe aus header file */
int f(int); /* -1 falls was kaputt ist */
int g(int); /* -1 falls was kaputt ist */

/* kreative Nutzung */
int int_hat_plus = f(...) + g(...);

Die Summe von zwei Fehleranzeigern wäre zwar formal korrekt,
aber wenn f(...) == -1 und g(...) == +1 ist, dann ist eben die
Deutung des Ergebnisses 0 als fehlerfrei höchst zweifelhaft.
Da kann "int" selbst nichts dafür. Aber die Schnittstelle der
Ganzzahlen kann mit Hilfe geeigneter Typen (und etwas Mühsal)
derart zweifelhaften Programmen etwas vorbeugen.

Ein Beispiel packe ist der Länge wegen ("Mühsal"...) in eine
weitere Antwort.

Eine dicke Schnittstelle abstrahiert Details und nimmt dafür
Steuermöglichkeiten weg. Bspw. fallen Wahlmöglichkeiten von
Funktionen zu Gunsten einer einzigen weg. Sie nimmt einem
die Wahl ab.
Helmut Schellong
2018-09-25 12:47:49 UTC
Permalink
Post by Rainer Weikusat
Post by Helmut Schellong
Post by Rainer Weikusat
[...]
Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.
Dh die Annahme mit dem "nichtdarstellbaren Wert" den eine Addition noch
irgendmandes Meinung haben sollte, obwohl sie den nicht hat, kann nur
auf Typen zutreffen, deren Groesse groesser oder gleich der Groesse von
int ist.
[...]
Es kann ein Wert rechts auf (long long) gewandelt werden.
Dann findet alles auf dieser Ebene statt.
Sicher kann das so gemacht werden. Andererseits ist die Annahme, eine
Maschinenaddition koenne oder solle in hypothetisches "nicht
darstellbares Resultat" haben, weil des jemanden zufaellig in den Kram
passt, ohnehin Quatsch. Aber um etwas real existierendes geht es in
dieser Diskussion ohnehin nicht und obiger Beitrag sollte bloss
aufzeigen, dass die zugrundeliegenden Annahmen noch nicht mal mit sich
selber konsistent sind, weil vorzeichenbehaftete Ganzahlen ohne
technische Begruendung in zwei Gruppen aufgeteilt werden.
In der Realität kann es Werte, die nicht repräsentiert werden
können, nicht geben - das ist klar.
Zumindest nicht bei 2er-Komplement.

Ich hatte vor 10 Tagen gepostet:
----------------------------------------------------------
Unter x86 gibt es gar kein problematisches Verhalten:
1# echo $((~0))
-1
2# echo $((~0+1))
0
3# echo $((~0+2))
1
4# echo $((~0>>1))
9223372036854775807
5# echo $(([~0>>1]+1))
-9223372036854775808
6# echo $(([~0>>1]+2))
-9223372036854775807
7# echo $(([~0>>1]-1))
9223372036854775806
8#
----------------------------------------------------------

1# echo $(([~0>>1]+111-111))
9223372036854775807

Es kann auch hin- und zurück-gewrapt werden.
Der Ursprungswert wird wieder erreicht.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2018-09-25 13:18:02 UTC
Permalink
Hallo,
Post by Helmut Schellong
In der Realität kann es Werte, die nicht repräsentiert werden
können, nicht geben - das ist klar.
Zumindest nicht bei 2er-Komplement.
Der Standard schreibt kein 2er-Komplement vor (obwohl das fuer die meisten
Compiler die uebliche Darstellung fuer Ganzzahltypen sein wird). Einer-
Komplement waere aber ebenfalls moeglich.
Post by Helmut Schellong
----------------------------------------------------------
Das ist fuer die Diskussionen, die hier OnTopic sind (Diskussionen ueber
den Standard) voellig wumpe, was bestimmte Implementierungen tun oder was
auf bestimmter Hardware ueblicherweise zu finden ist ...
Post by Helmut Schellong
Es kann auch hin- und zurück-gewrapt werden.
Der Ursprungswert wird wieder erreicht.
Der Standard garantiert das nicht. Er garantiert noch nicht einmal, dass
ein integer overflow nicht zu einem Programmabbruch fuehrt ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Schellong
2018-09-25 14:22:47 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Helmut Schellong
In der Realität kann es Werte, die nicht repräsentiert werden
können, nicht geben - das ist klar.
Zumindest nicht bei 2er-Komplement.
Der Standard schreibt kein 2er-Komplement vor (obwohl das fuer die meisten
Compiler die uebliche Darstellung fuer Ganzzahltypen sein wird). Einer-
Komplement waere aber ebenfalls moeglich.
Post by Helmut Schellong
----------------------------------------------------------
Das ist fuer die Diskussionen, die hier OnTopic sind (Diskussionen ueber
den Standard) voellig wumpe, was bestimmte Implementierungen tun oder was
auf bestimmter Hardware ueblicherweise zu finden ist ...
Post by Helmut Schellong
Es kann auch hin- und zurück-gewrapt werden.
Der Ursprungswert wird wieder erreicht.
Der Standard garantiert das nicht. Er garantiert noch nicht einmal, dass
ein integer overflow nicht zu einem Programmabbruch fuehrt ...
Das ist mir alles (als C-Buch-Autor) bestens bekannt.
Allerdings geht es in diesem Thread um reale Maschinenaddition
in Verbindung mir 2er-Komplement.


Und es werden jedes Jahr über 300 Millionen PCs weltweit abgesetzt.
In den 2020ern sollen es immer noch 250 Millionen PCs sein.
Die Anzahl vorhandener PCs dürfte weit über eine Milliarde betragen.
Was haben PCs für Prozessoren drin?
Praktisch zu 100% iX86 - mit 2er-Komplement und Little Endian!
Apple ist ja vor längerem von PPC(ibm) zu iX86 gewechselt;
auch Alpha-PCs von Vobis gibt es nicht mehr...
Und Server werden mit Xeon-X86 bestückt...

Die etwa 200 Stellen im C-Standard, wo dieser UB nennt, treffen
auf iX86 fast alle nicht zu.
Das ist die Realität - der man nicht entfliehen kann!
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Juergen Ilse
2018-09-25 14:56:41 UTC
Permalink
Hallo,
Post by Helmut Schellong
Das ist mir alles (als C-Buch-Autor) bestens bekannt.
Allerdings geht es in diesem Thread um reale Maschinenaddition
in Verbindung mir 2er-Komplement.
Nein, in diesem Thread ging es darum, ob und wenn ja wann es bei Ganzzahl-
arithmetik laut Standard "undefined behaviour" geben kann. Auch wenn einige
hier (auch du) einen Bezug zu realen Implementierungen herzustellen versuch-
ten, war das nicht Thema dieses Threads. Hier ging es um die Diskussion,
was der standard dazu sagt und nicht, was bestimmte Implementierungen um-
setzen. Un du weisst, dass beides ein deutlicher Unterschied sein kann.
Post by Helmut Schellong
Und es werden jedes Jahr über 300 Millionen PCs weltweit abgesetzt.
Wieviele Exemplare von welchem Computertyp und welchem C-Compiler pro Jahr
umgesetzt werden, ist fuer diese Diskussion voellig unerheblich. In dieser
Gruppe geht es um die Sprache wie im Standard spezifiziert und nicht um
konkrete Implementierungen.
Post by Helmut Schellong
Die etwa 200 Stellen im C-Standard, wo dieser UB nennt, treffen
auf iX86 fast alle nicht zu.
Das ist die Realität - der man nicht entfliehen kann!
...und in dieser Gruppe OffTopic. Hier geht es darum, was der Sprachstandard
besagt und nicht, was manche Leute in ihrer Implementierung der Sprache da-
rueberhinaus noch alles spezifizieren.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Helmut Schellong
2018-09-25 16:01:30 UTC
Permalink
Post by Juergen Ilse
Hallo,
Post by Helmut Schellong
Das ist mir alles (als C-Buch-Autor) bestens bekannt.
Allerdings geht es in diesem Thread um reale Maschinenaddition
in Verbindung mir 2er-Komplement.
Nein, in diesem Thread ging es darum, ob und wenn ja wann es bei Ganzzahl-
arithmetik laut Standard "undefined behaviour" geben kann. Auch wenn einige
hier (auch du) einen Bezug zu realen Implementierungen herzustellen versuch-
ten, war das nicht Thema dieses Threads. Hier ging es um die Diskussion,
was der standard dazu sagt und nicht, was bestimmte Implementierungen um-
setzen. Un du weisst, dass beides ein deutlicher Unterschied sein kann.
Dieser Thread heißt: "Mal noch ein anderer Ueberlaufsgedankengang"
und wurde gestern von Rainer W. gestartet.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2018-09-25 16:11:33 UTC
Permalink
Post by Juergen Ilse
Post by Helmut Schellong
Und es werden jedes Jahr über 300 Millionen PCs weltweit abgesetzt.
Wieviele Exemplare von welchem Computertyp und welchem C-Compiler pro Jahr
umgesetzt werden, ist fuer diese Diskussion voellig unerheblich. In dieser
Gruppe geht es um die Sprache wie im Standard spezifiziert und nicht um
konkrete Implementierungen.
Post by Helmut Schellong
Die etwa 200 Stellen im C-Standard, wo dieser UB nennt, treffen
auf iX86 fast alle nicht zu.
Das ist die Realität - der man nicht entfliehen kann!
...und in dieser Gruppe OffTopic. Hier geht es darum, was der Sprachstandard
besagt und nicht, was manche Leute in ihrer Implementierung der Sprache da-
rueberhinaus noch alles spezifizieren.
Die Realität, die übrigens standard-konform ist, ist d e r Maßstab
für mich, weil ich der Realität nicht entkommen kann.

Dem Standard hingegen kann ich entkommen, indem ich ihn komplett ignoriere.
Und es würde sich überhaupt gar nichts ändern durch dieses Ignorieren.

Aber ich habe den aktuellen Standard zur Verfügung, in Verbindung mit
meiner Eigenschaft als C-Buch-Autor.
Daher nehme ich den Standard zur Kenntnis, und vertrete ihn auch.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2018-09-25 18:58:27 UTC
Permalink
Post by Helmut Schellong
Dem Standard hingegen kann ich entkommen, indem ich ihn komplett ignoriere.
Tust du ja auch, mit schöner Regelmäßigkeit.
Post by Helmut Schellong
Aber ich habe den aktuellen Standard zur Verfügung, in Verbindung mit
meiner Eigenschaft als C-Buch-Autor.
Ich habe hier den "Schildt" liegen, der in schöner Weise demonstriert,
dass man als Autor von C-Büchern die Sprache nicht allzu gut
verstanten haben muss.

Das Buch ist schon ganz lustig: Auf einer Doppelseite findet man
links den Text der C89-Norm und rechts das, was der Autor dazu
geschrieben hat. Das sollte man besser ignorieren, weil es
zu dem, was links steht, nur zu häufig im Widerspruch steht.

Ein nicht so freundlicher Mensch hat das mal als "Rechts steht
der Text, links die Errata" zusammengefasst.

War damals aber eine schöne Gelegenheit, für recht wenig Geld
an die Norm zu kommen.

Und das beste C-Buch ist und bleibt eh K&R, 2. Auflage.
Helmut Schellong
2018-09-25 20:00:14 UTC
Permalink
Post by Thomas Koenig
Post by Helmut Schellong
Dem Standard hingegen kann ich entkommen, indem ich ihn komplett ignoriere.
Tust du ja auch, mit schöner Regelmäßigkeit.
Ich wüßte nicht, wo ich das tat.

Wenn ich über den Standard diskutiere und ihn auch mal kritisiere,
verlasse ich ihn damit nicht.
Ich verlasse ihn ebenso nicht, wenn ich über die standard-konforme
vorliegende Realität rede.
Post by Thomas Koenig
Post by Helmut Schellong
Aber ich habe den aktuellen Standard zur Verfügung, in Verbindung mit
meiner Eigenschaft als C-Buch-Autor.
Ich habe hier den "Schildt" liegen, der in schöner Weise demonstriert,
dass man als Autor von C-Büchern die Sprache nicht allzu gut
verstanten haben muss.
Das Buch ist schon ganz lustig: Auf einer Doppelseite findet man
links den Text der C89-Norm und rechts das, was der Autor dazu
geschrieben hat. Das sollte man besser ignorieren, weil es
zu dem, was links steht, nur zu häufig im Widerspruch steht.
Ein nicht so freundlicher Mensch hat das mal als "Rechts steht
der Text, links die Errata" zusammengefasst.
War damals aber eine schöne Gelegenheit, für recht wenig Geld
an die Norm zu kommen.
Und das beste C-Buch ist und bleibt eh K&R, 2. Auflage.
https://www.amazon.de/exec/obidos/ISBN=3642544363
Rezension:
=====================================================================
Als ergänzendes Werk liefert dieses Buch eine Fülle an tiefergehenden
Informationen zu den verschiedensten Aspekten der Programmiersprache
C, die man in den gängigen Lehrbüchern nicht findet.
Wer also schon mit C vertraut ist, der kann anhand dieses Buches
ja mal testen, wie gut er die Sprache wirklich verstanden hat. ;-)

Auch allgemeinere Themen, wie Portabilität, Modularisierung,
Optimierung, bsh, Vergleich mit anderen Sprachen, Paradigmen etc.
haben Eingang gefunden.

,----------
|Lobend zu erwähnen ist auch, dass sich dieses Buch nicht die
|Ungenauigkeiten und Schlampereien leistet, die sonst leider fast
|die gesamte deutschsprachige C-Literatur durchziehen.
'----------

Die wichtigsten Spracherweiterungen der (neuen) Standards C99 und C11
werden ausreichend abgehandelt.
=====================================================================

Mein Buch scheint doch sehr positiv abweichend zu sein.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2018-09-25 20:11:01 UTC
Permalink
Post by Helmut Schellong
Post by Thomas Koenig
Post by Helmut Schellong
Dem Standard hingegen kann ich entkommen, indem ich ihn komplett ignoriere.
Tust du ja auch, mit schöner Regelmäßigkeit.
Ich wüßte nicht, wo ich das tat.
Das ist ja das Problem.
Juergen Ilse
2018-09-25 22:55:12 UTC
Permalink
Hallo,
Post by Thomas Koenig
Post by Helmut Schellong
Dem Standard hingegen kann ich entkommen, indem ich ihn komplett ignoriere.
Tust du ja auch, mit schöner Regelmäßigkeit.
Ja (zumindest scheint es so) ...
Post by Thomas Koenig
Post by Helmut Schellong
Aber ich habe den aktuellen Standard zur Verfügung, in Verbindung mit
meiner Eigenschaft als C-Buch-Autor.
Ich habe hier den "Schildt" liegen, der in schöner Weise demonstriert,
dass man als Autor von C-Büchern die Sprache nicht allzu gut
verstanten haben muss.
Als der erschien, war er (wenn ich es richtig in Erinnerung habe, was ich
vor Jahren ueber dieses Buch gelesen habe), war das Buch *billiger* als
der unkommentierte C-Sprachstandard. Einige Leser fuehrten die Preis-
differenz auf die Qualitet der Kommentare zurueck ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
J***@fokus.fraunhofer.de
2018-10-06 22:04:32 UTC
Permalink
Post by Juergen Ilse
Nein, in diesem Thread ging es darum, ob und wenn ja wann es bei Ganzzahl-
arithmetik laut Standard "undefined behaviour" geben kann. Auch wenn einige
hier (auch du) einen Bezug zu realen Implementierungen herzustellen versuch-
ten, war das nicht Thema dieses Threads. Hier ging es um die Diskussion,
was der standard dazu sagt und nicht, was bestimmte Implementierungen um-
setzen. Un du weisst, dass beides ein deutlicher Unterschied sein kann.
Wenn es Rechner mit UNIX drauf sind, dann kannst Du seit 10 Jahren sicher davon
ausgehen, daß die 2-er Komplement Darstellung verwendet wird.


Das wird vom POSIX Standard so verlangt.
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
J***@fokus.fraunhofer.de
2018-10-06 22:08:57 UTC
Permalink
Post by Juergen Ilse
Hallo,
In der Realität kann es Werte, die nicht repräsentiert werden
können, nicht geben - das ist klar.
Zumindest nicht bei 2er-Komplement.
Der Standard schreibt kein 2er-Komplement vor (obwohl das fuer die meisten
Compiler die uebliche Darstellung fuer Ganzzahltypen sein wird). Einer-
Komplement waere aber ebenfalls moeglich.
Der POSIX Standard schreibt 2er Komplement vor!
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Ralf Damaschke
2018-09-25 00:18:26 UTC
Permalink
Post by Rainer Weikusat
Die C-Norm wuerde hier also *falls* eine Implementierung
Ganzahltypen hat, die kleiner als int sind, implementierungsabhaengiges
Verhalten fordern und fuer andere angeblich kein Verhalten definieren
waehrend das Verhalten fuer Implementierungen, bei denen int der
kleinste Typ ist, immer undefiniert waere, oder, kuerzer: Ob
Ganzahlueberlauf undefiniertes Verhalten hat ist durch die C-Norm selber
undefiniert. Meta-undefiniertes Verhalten!
Das stimmt so nicht. Operationen wie die Addition werden immer auf Typen
mit mindestens 'int'-Rang durchgeführt. Dabei kann zu UB kommen. Wenn ich
das Ergebnis dann von 'int' in ein 'char'-Objekt (oder auch von
'unsigned long long' nach 'int') übertrage, kann es (auch ohne vorigem UB)
zu dem in 6.3.1.3 implementierungs-definiertem Verhalten führen.
Post by Rainer Weikusat
Die gcc-Norm sieht das halt anders aber nu ja ...
Die Existenz einer Implementierung, die ein in der C-Norm undefiniertes
Verhalten in selbst definierter Weise behandelt, hat keine Rückwirkung
auf die Gültigkeit der Aussage in der C-Norm.
Loading...