[C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet

[60000 (Gast)]

Den meisten wird es bekannt sein. In dieser Ausprägung kannte ich das 
Problem aber selbst noch nicht, daher poste ich es mal dem Forum.

void setup() {
  Serial.begin(9600);

  uint32_t i = 30000 * 2; // Das ergibt keine 60000, sondern 4294934528
  Serial.println(i);

  uint32_t i = 30000 * 2L; // Das ergibt 60000
  Serial.println(i);
}

void loop() {
}

Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher 
davon ausgegangen, dass der Compiler gleich 32 Bit berechnet. Weil ihm 
ja der Typ (uint32_t) bekannt ist. Ist das nicht fast schon ein 
Compilerfehler?

[60000 (Gast)]

Die Erklkärung noch:

Aus "30000 * 2" macht der Compiler ein int. Dadurch entsteht ein 
negativer Wert. Dieser negative Wert wird in unsigned long gespeichert, 
wodurch er a) wieder positiv wird und  b) zum zweiten Mal seine Größe 
ändert.

[2⁵ (Gast)]

Man sollte seinen Compiler kennen: Du verwendest wohl einen AVR, da 
rechnet der gcc intern halt standardmäßig mit 16 Bit ints. Ein gcc für 
ARM Cortex-M würde hier mit 32 Bit ints rechnen.

[Stefan F. (Gast)]

Zahlen sind in C immer int, solange sie dort rein passen.

Bei Mathematischen Ausdrücken wird der Typ des grössten Argumentes 
verwendet. In deinem Fall sind beide Zahlen int, also wird mit einem 
Algorithmus für int gerechnet. Wohin das Ergebnis des Ausdrucks 
geschrieben wird, spielt keine Rolle.

> Ist das nicht fast schon ein Compilerfehler?

Nein, so ist C halt, es war nie anders. C ist an vielen Stellen 
unnatürlich.

Bei Java hatte man angekündigt, mit allen Altlasten und Überraschungen 
von C aufräumen zu wollen, aber auch dort gibt es trotzdem viele 
derartiger Überraschungen.

[c-hater (Gast)]

60000 schrieb:

> Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher
> davon ausgegangen, dass der Compiler gleich 32 Bit berechnet.

C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten 
würde.

Aber immerhin: es ist penibel und umfassend dokumentiert, was sie 
tatsächlich machen. Man sollte den Umfang dieser Doku vollständig 
beherrschen, BEVOR man es wagt, diese hochgefährlichen Sprachen zu 
benutzen, die offensichtlich genau dafür designed wurden, jegliche 
Erwartungen eines sinnvollen Grundverhaltens gnadenlos zu enttäuschen...

[Doris (Gast)]

Stefanus F. schrieb:
> Bei Mathematischen Ausdrücken

es müsste heißen: Bei mathematischen Ausdrücken.

Das Wort "mathematisch" ist in diesem Zusammenhang kein Nomen und wird 
klein geschrieben, so lang es nicht am Anfang eines Satzes steht!

[Stefan F. (Gast)]

c-hater schrieb:
> C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten
> würde.

War ja klar, das das wieder kommt. Gut dass dich schon lange niemand 
mehr ernst nimmt. Bewerbe dich mal bei Putins Propaganda-Troll-Fabrik.

[Markus Roge (Gast)]

c-hater schrieb:
> BEVOR man es wagt, diese hochgefährlichen Sprachen zu
> benutzen

Welche Sprache nutzt du eigentlich? Nur Assembler?

[Sven P. (Gast)]

60000 schrieb:
> Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher
> davon ausgegangen, dass der Compiler gleich 32 Bit berechnet. Weil ihm
> ja der Typ (uint32_t) bekannt ist. Ist das nicht fast schon ein
> Compilerfehler?
Nein, die rechte Seite der Zuweisung wird unabhängig von der linken 
Seite bewertet.

Die Erklärung hinkt auch etwas. Genaugenommen macht der Compiler aus 
30000 und aus 2 jeweils den kleinsten Integer-Typen, der passt (int, 
long int oder long long int). Bei dir ist int nunmal 16 Bit breit.
Die Berechnung wird bei int*int auch als int ausgeführt, und 2*30000 
passt da nicht mehr hinein.

c-hater schrieb:
> C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten
> würde.
Und in welcher Sprache wäre dieser Fehler deiner Meinung nach nicht 
exakt genauso passiert?
Kleiner Tipp: Es wäre in Delphi, TurboPascal und Visual Basic und Java 
semantisch genau so passiert.

[Falk B. (falk)]

60000 schrieb:
> Den meisten wird es bekannt sein. In dieser Ausprägung kannte ich das
> Problem aber selbst noch nicht, daher poste ich es mal dem Forum.

Tja, leider eine der vielen, kleine, fiesen Tücken von C.
Stichwort Integer Promotion.

uint32_t i = 30000L * 2;

Und schon geht's.

> Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher
> davon ausgegangen, dass der Compiler gleich 32 Bit berechnet.

Warum sollte er das?

> Weil ihm
> ja der Typ (uint32_t) bekannt ist.

Nö. Es wird zuerst mit dem Zahlenformat der rechten Seite berechnet und 
DANACH ggf. eine Typerweiterung/umwandlung durchgeführt. Darum erzeugt 
deine Rechung einen Overflo, denn int ist bei avr gcc 16 Bit.

> Ist das nicht fast schon ein
> Compilerfehler?

Nö. Das sind die Feinheiten von C. Muß man nicht mögen, ist aber so.

[Frotho (Gast)]

c-hater schrieb:

> diese hochgefährlichen Sprachen zu benutzen,

Jetzt aber ;-)

Sind die blutigen Spuren überall in den Wäldern also von dir. Ich weiß 
ja auch, dass es Bärenfallen gibt, aber in rede reitreten tue ich 
nicht ^^

[Veit D. (devil-elec)]

Hallo,

immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die 
Warnungen einschaltet.

Ansonsten schreib das meinetwegen so.

uint32_t b = 30000; 
uint32_t c = b * 2; 
Serial.println(c);

[Frotho (Gast)]

Falk B. schrieb:

>

> uint32_t i = 30000L * 2;
>

>
> Und schon geht's.

uint32_t i = 30000 * 2L;

Geht auch.

Er siehts also, der Compiler.

Wieso er dann das uint32_t übersieht, ist eigentlich unerklärbar.

Ist so, als wenn man dem Bäcker einen Korb für Brötchen hinhält und 
sagt: "5 mal ..." ... aber dann geht gerade das Telefon, und bevor man 
weiter reden und "5 mal ... 10 Brötchen" sagen kann, hat der Bäcker 
schon die ersten fünf in die kleine Tüte reingezählt.

Ich finde, zwischen Bäckern und Programmierern ist -manchmal- nicht so 
ein großer Unterschied ^^

[Stefan F. (Gast)]

Veit D. schrieb:
> immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die
> Warnungen einschaltet.

Die IDE warnt vor gar nichts, das macht der avr-gcc Compiler.

[Frotho (Gast)]

Veit D. schrieb:

> immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die
> Warnungen einschaltet.

Ja, klar. Minniprogramm-Schreiber, oder Masochist. Was bist du?

[Stefan F. (Gast)]

Frotho schrieb:
> Wieso er dann das uint32_t übersieht, ist eigentlich unerklärbar.

Die Antwort hast du bereits zweimal erhalten: Die Typen der Argumente 
des Ausdrucks werden verwendet. Das Ziel wo das Ergebnis gespeichert 
wird, spielt keine Rolle bei der Auswertung des Ausdrucks.

Das ist halt so festgelegt worden und zahlreiche Programme verlassen 
sich darauf, das sich festgelegte Sachen nie ändern.

> Ist so, als wenn man dem Bäcker einen Korb für Brötchen hinhält

Nein, das ist so als ob du 10 Brötchen bestellt aber einen zu kleinen 
Korb dazu mitbringst. Das ist dem Bäcker ziemlich egal.

[Falk B. (falk)]

Veit D. schrieb:
> Hallo,
>
> immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die
> Warnungen einschaltet.

Sind aber nicht, was eher doof ist. Und der Arduino-Normalo kann die 
auch nicht einschalten.

> Ansonsten schreib das meinetwegen so.uint32_t b = 30000;
> uint32_t c = b * 2;
> Serial.println(c);

Nö, eher so.

Beitrag "Re: [C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet"

Oder so.

https://www.mikrocontroller.net/articles/Festkommaarithmetik#Die_L.C3.B6sung

Bissel runter gehen, bei "Achtung!"

Bei Konstanten muss man halt die passende Endung wählen.

L = long, meist 32 Bit
UL = unsigned long
LL = long long, meist 64 Bit
ULL = unsigned long long

Oder einen Cast vor die Konstante oder Variable setzen und die EXAKTEN 
Datentypen aus stdint.h nutzen, da weiß man IMMER was man bekommt!

uint32_t i = (uint32_t)30000 * 2;

[Sven P. (Gast)]

Frotho schrieb:
> Wieso er dann das uint32_t übersieht, ist eigentlich unerklärbar.
Er übersiehts ja nicht, aber es kommt halt später erst an die Reihe.

Und warum das so ist?
Naja, weil man in der Regel nicht jede Berechnung gleich breit auswalzen 
möchte.

Es ist ja völlig legitim, dass du in dem Term astronomische 
Zwischenergebnisse hast, die letztlich wieder kleingemacht werden 
(Division, rechts-schieben) und in die Variable auf der linken Seite der 
Zuweisung passen.
Dann wärs ja auch Käse, wenn der Compiler den Typ der Variablen annehmen 
würde.

Mach dir Gedanken, ob die Ergebnisse in die Variablen passen. Das musst 
du ja letztlich in jeder Programmiersprache.

[(prx) A. K. (prx)]

Mindestens Anfänger, manchmal auch Fortgeschrittere, gehen oft davon 
aus, dass bei einem Statement der Art
     xxx_t Variable = Rechenausdruck;
offensichtlich sei, dass der Rechenausdruck in der Breite von xxx_t 
erfolgt. Das stünde ja doch deutlich genug da.

Pustekuchen! Der Rechenausdruck wird isoliert betrachtet, ohne Rücksicht 
auf den Kontext. Erst das Ergebnis dieser Erwägung wird an xxx_t 
angepasst.

[Sven P. (Gast)]

Falk B. schrieb:
> Oder einen Cast vor die Konstante oder Variable setzen und die EXAKTEN
> Datentypen aus stdint.h nutzen, da weiß man IMMER was man bekommt!

Dazu gibts sogar recht elegant Makros in stdint.h: INT32_C und so 
weiter.

[Frotho (Gast)]

Falk B. schrieb:

> Nö. Das sind die Feinheiten von C. Muß man nicht mögen, ist aber so.

"Feinheiten", wo man Bug und Feature nicht mehr auseinander halten kann, 
kenne ich nur von M$ Produkten, und um die mache ich einen großen Bogen, 
wo immer es möglich ist.

Die sogenannten "Feinheiten" sind im übrigen der Grund, dass man 
heutzutage noch solche Fragen stellen muss
Beitrag "Welche Berechnungen erfolgen durch Präprozessor ?"
und dass da auch noch zu lesen ist, um wieviel besser die Compiler zu 
ano damalsmal geworden sind...nichts ist besser. Nur die Klippen, die 
damals backbord waren, sind heute steuerbord. Raider heißt jetzt ....

[Stefan F. (Gast)]

Fast alle Programmiersprachen verhalten sich so. Also wäre ich mit dem 
Meckern besser mal vorsichtig, zumindest wenn ich mit Programmieren 
meinen Lebensunterhalt erwirtschaften möchte.

[M.K. B. (mkbit)]

Ich hab das ganze mal kurz im Onlinecompiler mit dem MSP420 gcc 6.2.1 
probiert. Da bekomme ich warning: integer overflow in expression 
[-Woverflow].
Wenn man also die richtigen Warnings einschaltet, dann meckert der 
Compiler auch.

[Frotho (Gast)]

Stefanus F. schrieb:
> Fast alle Programmiersprachen verhalten sich so. Also wäre ich mit dem
> Meckern besser mal vorsichtig, zumindest wenn ich mit Programmieren
> meinen Lebensunterhalt erwirtschaften möchte.

Du hast ja recht. Nörgeln am Essen ist genau so unangenehm. Aber für 
wen? Für den Gast, oder die Küche ..

Wer sich nie beklagt, muss alles essen, was ihm hingeworfen wird. Suche 
den Unterschied zwischen einem Programmierer und einem Straßenhund ...

Will sagen, dass ich auch im Beruf "meckere". Wenn es einen Grund gibt, 
sage ich das natürlich. Die meisten Kollegen und das aber nicht. Fahren 
sie besser als ich? Ich vermute: ja.

Der ET ist aber nicht zmm meckern, sondern um jenen etwas mitzuteilen, 
die vielleicht noch nicht wissen, wie sich fast alle Programmiersprachen 
verhalten ;-)

[(prx) A. K. (prx)]

Wen es interessiert, weshalb das so ist: Bei dem Statement
   long Variable = a*b;
liesse sich die Rechenweise von a*b aus dem Kontext ableiten.

Hier allerdings wäre das nicht mehr so einfach möglich:
   long Variable = (long)(a*b);  // C
   long Variable = long(a*b);    // C++
Denn aus (int)(a*b) oder int(a*b) lässt sich nicht mehr auf die Breite 
der Berechnung von a*b schliessen.

Man müsste Konstruktionen wie
   long Variable = convert<long,int>(a*b);
verwenden, in denen bei in der Konvertierung nicht nur der Typ vom 
Ergebnis, sondern auch der vom Operanden angegeben wird. Erst dadurch 
würde a*b eindeutig.

[Dr. Sommer (Gast)]

Frotho schrieb:
> Feinheiten", wo man Bug und Feature nicht mehr auseinander halten kann,

Sinnloses Gezeter. Kontextfreie Sprachen, insbesondere viele 
Programmiersprachen, funktionieren nun einmal so, dass Ausdrücke von 
innen nach außen ausgewertet werden. Also erst die 30000, dann die 2, 
dann deren Produkt (inkl. Überlauf) und dann erst die Zuweisung unter 
Beachtung von uint32_t. Das ist einfach die grundlegende Funktionsweise 
von Ausdrücken und Parsern. Eine von außen dran geschriebene Information 
innen einzubringen würde die ganze Struktur der Sprache durcheinander 
bringen und das Typsystem dramatisch verkomplizieren. Wahrscheinlich 
lässt sich das gar nicht allgemeingültig aufbauen (wie würde sich das 
auf Funktionsaufrufe auswirken, auf verschachtelte Ausdrücke, auf 
Templates...?). Also damit abfinden und weniger jammern.

[Frotho (Gast)]

M.K. B. schrieb:

> Wenn man also die richtigen Warnings einschaltet, dann meckert der
> Compiler auch.

Noch einer. Was schreibt ihr alle für Miniprogramme? Ich habe 1x die 
Warnings eingeschaltet und bin fast erschlagen worden von 
unused-parameter Warnings. Das brauche ich nicht. Jedenfalls nicht bei 
jedem Compilieren. Wenn ich fertig bin, ja, zum optimieren und für QS. 
Aber nicht bei jedem Mal, da schwillt mir ja der Kopf.

Habs gerade mal in ein Word doc kopiert: 16 A4-Seiten

[Frotho (Gast)]

Dr. Sommer schrieb:
> Frotho schrieb:
>> Feinheiten", wo man Bug und Feature nicht mehr auseinander halten kann,
>
> Sinnloses Gezeter.

NEIN ! Du bist konditioniert, das ist alles.

[Jemand (Gast)]

Frotho schrieb:
> Noch einer. Was schreibt ihr alle für Miniprogramme?

Was schreibst du eigentlich für beschissenen Code?

Frotho schrieb:
> Ich habe 1x die
> Warnings eingeschaltet und bin fast erschlagen worden von
> unused-parameter Warnings.

Die kannst du individuell abschalten.

[foobar (Gast)]

> Mindestens Anfänger, manchmal auch Fortgeschrittere, gehen oft davon
> aus, dass bei einem Statement der Art
>     xxx_t Variable = Rechenausdruck;
> offensichtlich sei, dass der Rechenausdruck in der Breite von xxx_t
> erfolgt.

Hier auch?

uint16_t x = 3.3 * 1000;

Es schon sinnvoll, dass ein und der selbe Ausdruck immer das gleiche 
Resultat liefert, egal in welchem Kontext er steht.  Der Kontext 
entscheidet dann, wie das Resultat verwurstet wird.

[(prx) A. K. (prx)]

Dr. Sommer schrieb:
> Sinnloses Gezeter.

Yep.

> Kontextfreie Sprachen, insbesondere viele
> Programmiersprachen, funktionieren nun einmal so, dass Ausdrücke von
> innen nach außen ausgewertet werden.

Der Begriff einer "kontextfreien Sprache" bezieht sich üblicherweise auf 
die Grammatik/Syntax. Die ist hier aber nicht entscheidend, denn die 
Ableitung der Bedeutung, hier der Rechenweise, ist nicht Teil der 
Grammatik.

> würde die ganze Struktur der Sprache durcheinander
> bringen und das Typsystem dramatisch verkomplizieren.

Es käme eine völlig andere Sprache dabei heraus, oft deutlich 
umständlicher, weil Operatoren und Funktionen (C++ Overloading), die in 
generischer Weise auf verschiedene Typen anwendbar sind, wesentlich 
komplizierter gestalten würde. Das Gejammer würde sich nur verlagern.

Es läuft letztlich darauf hinaus, eine Fremdsprache mitsamt ihrem Wesen 
zu lernen und nicht zu versuchen, die muttersprachliche Intuition darauf 
anzuwenden.

[(prx) A. K. (prx)]

foobar schrieb:
> Hier auch?

Da sieht man es direkt. Im Problem des Startbeitrags nicht.

> Es schon sinnvoll, dass ein und der selbe Ausdruck immer das gleiche
> Resultat liefert, egal in welchem Kontext er steht.

Ich habe nichts anderes behauptet. ;-)

[M.K. B. (mkbit)]

Frotho schrieb:
> Noch einer. Was schreibt ihr alle für Miniprogramme? Ich habe 1x die
> Warnings eingeschaltet und bin fast erschlagen worden von
> unused-parameter Warnings.

Auch im produktiven Code in sehr großen Projekten haben wir die Warnings 
an. Für manche externen Bibliotheken sind die dann explizit teilweise 
ausgeschaltet.

Bisher war aber meine Erfahrung, dass die Warnings schon berechtigter 
Weise meckern und genau die hier beschriebenen Fehler aufdecken. Wenn 
die natürlich nicht gleich bei der Entwicklung an sind, dann kann es 
später erstmal Arbeit sein den Code entsprechend zu korrigieren. Aber 
einen Tod muss man sterben.

[zitter_ned_aso (Gast)]

Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis?

uint32_t x = (int16_t)30000*(int16_t)2;
printf("%u\n", x);

int16 mal int16 musste doch vom Typ her auch int16 ergeben? (und somit 
das falsche Ergebnis)

[(prx) A. K. (prx)]

Frotho schrieb:
> NEIN ! Du bist konditioniert, das ist alles.

Ist er, genauso wie ich. Das bringt beispielsweise ein Informatikstudium 
so  ich sich. Lernen bedeutet konditioniert zu werden, in einer 
bestimmten Weise zu denken.

[Falk B. (falk)]

zitter_ned_aso schrieb:
> Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis?
> uint32_t x = (int16_t)30000*(int16_t)2;
> printf("%u\n", x);

Weil int16_t vorzeichenbehaftet von -32768 bis 32767 geht?

> int16 mal int16 musste doch vom Typ her auch int16 ergeben?

Nö. 16 Bit * 16 Bit sind 32 Bit. Das Ergebnis fürht nur dann nicht zum 
Überlauf, wenn die Faktoren klein genug sind.

> (und somit das falsche Ergebnis)

[(prx) A. K. (prx)]

zitter_ned_aso schrieb:
> Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis?

Weil durch %u ein implizites
  printf("%u\n", (unsigned)x);
drin steckt.

Abgesehen davon, dass in
  printf("%u\n", x);
4 Bytes übergeben aber nur 2 Bytes abgeholt werden. Was bei
  printf("%u,%u\n", x, x);
je nach Umgebung voll in die Hose gehen kann.

Allerdings ist dein Code sowieso undefiniert, weil Überlauf mit 
Vorzeichen. Und undefinierter Code muss nicht immer dein Haus zu 
Einsturz bringen. Er kann auch so arbeiten, wie man es eigentlich haben 
wollte.

Soll heissen: Bloss weil sich ein Programm so verhält, wie man es 
erwartet, ist es noch lange nicht korrekt.

[(prx) A. K. (prx)]

Falk B. schrieb:
>> int16 mal int16 musste doch vom Typ her auch int16 ergeben?
>
> Nö. 16 Bit * 16 Bit sind 32 Bit.

In PL/I schon. In C nur dann, wenn ein "int" 32 Bits breit ist.

[Stefan F. (Gast)]

Frotho schrieb:
> Was schreibt ihr alle für Miniprogramme? Ich habe 1x die
> Warnings eingeschaltet und bin fast erschlagen worden von
> unused-parameter Warnings. Das brauche ich nicht.

Man kann Programme (auch grosse) so schreiben, dass fast keine Warnungen 
erscheinen. Die wenigen, die übrig bleiben kann man stellenweise 
unterdrücken. Dann aber bitte mit Kommentar, was man sich dabei gedacht 
hat.

Siehe: #pragma warning

Ich programmiere beruflich in Java. Dort benutze ich zusätzlich zu den 
Warnungen des Compiler das Tool FindBugs mit projektspezifischer 
Konfiguration. Das Pendant dazu in C/C++ wäre lint.

Diese Tools halte ich äusserst hilfreich. Sie helfen sehr dabei, dumme 
Fehler zu vermeiden - selbst wenn die meisten Warnungen falsche Treffer 
sind.

> Habs gerade mal in ein Word doc kopiert: 16 A4-Seiten

Das ist gar nichts! Ich arbeite an Programmen mit mehreren hundert 
Tausend Zeilen Quellcode (nicht Kommentare).

[leo (Gast)]

A. K. schrieb:
> Abgesehen davon, dass in
>   printf("%u\n", x);
> 4 Bytes übergeben aber nur 2 Bytes abgeholt werden. Was bei
>   printf("%u,%u\n", x, x);
> je nach Umgebung voll in die Hose gehen kann.

Wo werden da Bytes "abgeholt"? Was geht nicht?
Bitte bring ein Beispiel.

leo

[A. S. (Gast)]

Frotho schrieb:
> Veit D. schrieb:
>
>> immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die
>> Warnungen einschaltet.
>
> Ja, klar. Minniprogramm-Schreiber, oder Masochist. Was bist du?

Eigentlich haben nur Anfänger die Warnungen generell ausgeschaltet, 
abgesehen von z.b.legacy Code oder so.

Profis haben alle Warnungen an, bis sie jede einzelne dann abschalten, 
wenn sie sie verstanden haben und die Effekte keine Gefahr mehr 
darstellen.

Experten zwingen sich zusätzlich noch unter weit strengere, permanente 
Überwachung, z.b. MISRA-C.

[zitter_ned_aso (Gast)]

A. K. schrieb:
> Weil durch %u ein implizites
>   printf("%u\n", (unsigned)x);
> drin steckt.

unsigned habe ich jetzt weggelasen.

int32_t x = (int16_t)30000*(int16_t)2;
printf("%d\n", x);

Und wieder kommt das richtige Ergebnis raus.

Falk B. schrieb:
> Nö. 16 Bit * 16 Bit sind 32 Bit.

size_t size  = sizeof((int16_t)30000*(int16_t)2);
printf("x: %zd\n", size);

gibt tatsächlich 4 aus. (ist Standard-Int auf meinem System)

Und ich dachte wenn man z.B. (short) + (char) rechnet, dann bekommt das 
Ergebnis implizit den größten Datentyp von beiden (also short).

[foobar (Gast)]

> Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis?
>  uint32_t x = (int16_t)30000*(int16_t)2;

Weil in C alle Berechnungen in mindestens int-Größe stattfinden, die 
ints auf deinem PC sind 32-bit.  Deine Casts verkleinern die 
(int-)Zahlen nur (hier ohne Effekt), danach kommen die impliziten Casts 
auf int.

[(prx) A. K. (prx)]

leo schrieb:
> Wo werden da Bytes "abgeholt"? Was geht nicht?
> Bitte bring ein Beispiel.

Die Funktion printf("%u,&u",a,b) mit 32bit Typen a und b kennt keine 
definierten Parametertypen jenseits des Formatstrings. Ein Weg, das zu 
implementieren, geht über einen Stack. Übergeben werden die realen Typen 
von a und b, ohne Berücksichtigung des Formatstrings. Das kann dann auf 
einem abstrahierten 16-Bitter so aussehen:
   push 32bit b
   push 32bit a
   push 16bit address of "%u,%u"
   call printf
   add sp, #10
Die Funktion printf wird aus dem Formatstring ableiten, dass 2 16-Bit 
Werte auf dem Stack stehen. Das sind dann die beiden Hälften von "a". Je 
nachdem ob big- oder little-endian gibts die obere Hälfte vorne, oder 
die untere

[Frotho (Gast)]

M.K. B. schrieb:
> Bisher war aber meine Erfahrung, dass die Warnings schon berechtigter
> Weise meckern

Kann ja sein. Aber unused-Parameter (75%) brauche ich nicht gemeldet zu 
sehen, weiß ich selbst (meist optionalen Parametern).

[(prx) A. K. (prx)]

zitter_ned_aso schrieb:
> Und ich dachte wenn man z.B. (short) + (char) rechnet, dann bekommt das
> Ergebnis implizit den größten Datentyp von beiden (also short).

Alles kleiner als int wird zu int. Erst wenn ein grösserer Typ als int 
mitspielt, stimmt das, was du schreibst.

[zitter_ned_aso (Gast)]

foobar schrieb:
> Weil in C alle Berechnungen in mindestens int-Größe stattfinden

Ja, jetzt klingelt's. Danke!

[foobar (Gast)]

> Und ich dachte wenn man z.B. (short) + (char) rechnet, dann bekommt das
> Ergebnis implizit den größten Datentyp von beiden (also short).

Eben nicht.  In der theoretischen Maschine von C gibt es keine 
Multiplikation/Addition/etc mit Zahlen kleiner als int.  Wenn du das in 
dem erzeugten Kode findest, war das der Optimizer, der das "verkleinert" 
hat.

[Frotho (Gast)]

A. S. schrieb:
> Eigentlich haben nur Anfänger die Warnungen generell ausgeschaltet,
> abgesehen von z.b.legacy Code oder so.

Wenn das so ist, bin ich Anfänger ;)

[Frotho (Gast)]

Stefanus F. schrieb:

> Man kann Programme (auch grosse) so schreiben, dass fast keine Warnungen
> erscheinen. Die wenigen, die übrig bleiben kann man stellenweise
> unterdrücken. Dann aber bitte mit Kommentar, was man sich dabei gedacht
> hat.

Das halte ich auch so. Wenn das Programm fertig ist, will ich keine 
Warnung mehr am Bildschirm sehen. Erst mal ist wichtig, dass das Prog 
die Anforderungen erfüllt, möglichst 100% feherlfrei, DANN kümmere ich 
mich um unused-Parameter. Ich hoffe, du machst das auch so. Und JA, es 
sind fast nur unused-Parameter. Warum soll ich mir da einen Kopf machen 
und Arbeitszeit verschwenden? Das stört mich AKTUELL überhaupt nicht.

Frotho schrieb:

> Wenn ich fertig bin, ja, zum optimieren und für QS.

[leo (Gast)]

A. K. schrieb:
> Übergeben werden die realen Typen
> von a und b, ohne Berücksichtigung des Formatstrings.

Ah, du sprichst von einer vollkommen kaputten Compiler, der keinerlei 
Vergleich der printf Argumente vornimmt.

$ cat x.c
#include <stdio.h>
int main()
{
  int a = 10;
  printf("%f\n", a);
}
$ gcc x.c && ./x.out
x.c: In function ‘main’:
x.c:5:12: warning: format ‘%f’ expects argument of type ‘double’, but argument 2 has type ‘int’ [-Wformat=]
   printf("%f\n", a);
           ~^
           %d

Also wohl veraltet oder theoretisch.

leo

[Frotho (Gast)]

Wie dem auch sei, jeder wie er mag. Die Diskussionsbeteiligung sagt 
jedenfalls, dass das Thema nicht ganz unnütz gewesen sein kann.

[(prx) A. K. (prx)]

leo schrieb:
> Ah, du sprichst von einer vollkommen kaputten Compiler, der keinerlei
> Vergleich der printf Argumente vornimmt.

Ich trenne Sprache von Compiler, spreche von der mir recht gut 
vertrauten Sprache C, nicht von einem bestimmten Compiler.

> Also wohl veraltet oder theoretisch.

GCC tut dem Programmierer den Gefallen, Formatstring und Parameter 
gegenzuchecken. Das ist aber keine Spracheigenschaft. Denk dir 
printf(s,a,b) mit einem dem Compiler unbekannten String s, und der Traum 
platzt.

[leo (Gast)]

A. K. schrieb:
> GCC tut dem Programmierer den Gefallen, Formatstring und Parameter
> gegenzuchecken. Das ist aber keine Spracheigenschaft.

Ok. Ich verwende halt einen Compiler der fuer mich funktioniert.
Aber du hast schon recht.

leo

[no c tomorrow, no sorrow (Gast)]

Schon richtig, C ist Sch... und nicht mehr zeitgemäß.
Mal schauen, wie lange die Selbsterhaltungsstrategie der ach so 
supertollen C-Programmierer noch funktioniert. ;-)

Und ja, ich muss mich seit Jahren mit der Sch... rumärgern und damit 
mein Geld verdienen. :-<<<

[Wilma Streit (Gast)]

Doris schrieb:
> Stefanus F. schrieb:
>> Bei Mathematischen Ausdrücken
>
> es müsste heißen: Bei mathematischen Ausdrücken.
>
> Das Wort "mathematisch" ist in diesem Zusammenhang kein Nomen und wird
> klein geschrieben, so lang es nicht am Anfang eines Satzes steht!

Das ist einfach zu gut! Da belehrt man andere in ihrer Rechtschreibung 
und dann ist doch tatsächlich der erste Buchstabe in diesem lehrreichen 
Text falsch. Wenn das keine Satire ist...

[(prx) A. K. (prx)]

no c tomorrow, no sorrow schrieb:
> Und ja, ich muss mich seit Jahren mit der Sch... rumärgern und damit
> mein Geld verdienen. :-<<<

Je dümmer die Sprache, desto mehr Stunden kostet es.
Diese Dummheit lässt also deine Kasse klingeln! ;-)

[Carl D. (jcw2)]

Frotho schrieb:
> A. S. schrieb:
>> Eigentlich haben nur Anfänger die Warnungen generell ausgeschaltet,
>> abgesehen von z.b.legacy Code oder so.
>
> Wenn das so ist, bin ich Anfänger ;)

Full ACK,
denn Fortgeschrittene wissen das man dem Compiler mit

int funktion( int parm1, int unbenutzt) {
       (void)unbenutzt;
  ...
}

mitteilen kann, daß das mit Wissen und Absicht passiert.

[Dumdi D. (dumdidum)]

c-hater schrieb:
> C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten
> würde.

Einerseits ja, andererseits sind das die einzigen brauchbaren Sprachen 
ohne GC (ok, abgesehen von ADA). Rust ist noch nicht so weit.

[Stefan F. (Gast)]

Frotho schrieb:
> unused-Parameter. Warum soll ich mir da einen Kopf machen

Weil das auch ein Hinweis auf einen Fehler sein kann. Beispiel:

double reduceBillingAmount(double amount, double reduceBy)
{
  return amount-amount;
}

Hier bekommst du so eine Fehermeldung und das ist auch gut so, weil 
deine Firma sonst nach dem Deployment dieser Software pleite geht.

[Stefan F. (Gast)]

A. K. schrieb:
> printf()
> GCC tut dem Programmierer den Gefallen, Formatstring und Parameter
> gegenzuchecken.

Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese 
Kontrolle leider nicht.

[x^y (Gast)]

Der Überlauf eines signed Typs ist übrigens nach Standard undefiniert. 
Das Ergebnis hätte also auch 42 lauten können.

Die meisten C Programmierer gehen leider mit Konstanten und signed Typen 
relativ sorgenfrei um. Man muss aber sagen: Auch Konstanten haben einen 
Typ und signed Typen zeigen wesentlich häufiger undefiniertes Verhalten 
als unsigned Typen.

Daher ein gut gemeinter Tipp: Konstanten immer durch passendes Postfix 
in den gewünschten Typ setzen und immer unsigned Typen verwenden sofern 
kein vorzeichenbehafteter Typ explizit notwendig ist.

Selbst harmlos aussehende Dinge wie

int f(int n)
{
   return 1 << n;
}

sind mit signed Typen der absolute Horror, da gleich mehrfach 
undefiniertes Verhalten auftreten kann: n kann negativ sein => 
undefiniert, n kann größer als int Bitlänge sein => undefiniert, 1 
(signed, daher Ausdruck int op int) kann ins Vorzeichen geschoben werden 
=> undefiniert

[Stefan F. (Gast)]

x^y schrieb:
> Selbst harmlos aussehende Dinge wie...sind mit signed Typen der absolute Horror

Das hast du sehr schön beschrieben. Ich habe mich schon darüber 
gewundert, dass in der CMSIS Core hinter sämtlichen Integer Literalen 
"U" oder "UL" steht.

#define APSR_N_Pos   31U 
#define APSR_N_Msk   (1UL << APSR_N_Pos)

Nach deiner Erklärung ergibt es absolut Sinn!

[x^y (Gast)]

c-hater schrieb:
> Aber immerhin: es ist penibel und umfassend dokumentiert, was sie
> tatsächlich machen. Man sollte den Umfang dieser Doku vollständig
> beherrschen, BEVOR man es wagt, diese hochgefährlichen Sprachen zu
> benutzen, die offensichtlich genau dafür designed wurden, jegliche
> Erwartungen eines sinnvollen Grundverhaltens gnadenlos zu enttäuschen...

Das ist so, damit der Compiler effizienten Code erzeugen kann. Würde man 
z.B. signed Überlauf präzise definieren, stünde man vor dem Problem, 
dass die Instruktionen der unterschiedlichen Architekturen sich nicht so 
verhalten. Der Compiler könnte dann nicht so einfach eine ADD oder MUL 
Instruktion erzeugen sondern müßte viel drum herum bauen damit er die 
Spezifikation einhalten kann. Da dieser Überbau aber in den seltensten 
Fällen wirklich notwendig wäre, ist das Overhead der das Programm 
ineffizienter macht.

c-hater schrieb:
> C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten
> würde.

Die Sprachen sind lediglich fair: Ich mache ja auch nicht alles was 
jeder dahergelaufene Trottel mir erwartet.

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese
> Kontrolle leider nicht.

Der GCC hat ein Attribut für printf-artige Funktionen, die entsprechend 
geprüft werden. Ist natürlich nicht portabel und schon eine Art Hack.
In C++ ist das mit std::cout viel besser - da wird immer automatisch 
richtig ausgegeben, abhängig vom tatsächlichen Typ. Leider sind die 
gängigen Implementationen davon nicht für uC geeignet.

Von wegen Warnungen - gerade im professionellen Bereich sollte man immer 
so viele Warnungen wie möglich aktivieren. Sie weisen auf potentielle 
Probleme hin, die man natürlich nicht erst beim Kunden, sondern 
möglichst früh finden möchte. Wenn der Code so schlecht ist, dass er 
seitenweise Warnungen produziert, sollte man ihn dringend korrigieren, 
denn zwischen den unnötigen Warnungen fallen die tatsächlichen Probleme 
nicht sehr auf. Das Korrigieren ist in den meisten Fällen auch gar kein 
Problem. Wenn man die Warnungen immer an hat, macht man das automatisch 
zwischendurch. Gute IDEs zeigen manche Warnungen auch schon beim Tippen 
an.
Ungenutzte Parameter sind gerade in C ein Zeichen für schlechten Code 
(kaum Polymorphie). Wie man diese mit dem (void)-Trick loswird wurde ja 
bereits gezeigt. In C++ taucht so etwas häufiger auf, da kann man aber 
einfach den Namen des Parameters weglassen, dann verschwindet die 
Warnung. So ist auch deutlich zu sehen dass der Parameter nicht genutzt 
wird.
Übrigens kann man auch bei Arduino die Warnungen im Optionsmenü 
einschalten. Leider sind sie das nicht standardmäßig.

Frotho schrieb:
> NEIN ! Du bist konditioniert, das ist alles.

Man sollte es nicht glauben, aber Jahrzehnte an Forschung und 
Entwicklung bringen durchaus sinnvolle Dinge zustande. Es hat oft schon 
seinen Grund, warum Dinge so sind wie sie sind. Wenn du es besser 
kannst, definiere deine eigene Sprache.

A. K. schrieb:
> Der Begriff einer "kontextfreien Sprache" bezieht sich üblicherweise auf
> die Grammatik/Syntax. Die ist hier aber nicht entscheidend, denn die
> Ableitung der Bedeutung, hier der Rechenweise, ist nicht Teil der
> Grammatik.

Stimmt zwar, aber aus der Grammatik und dem daraus entstehenden 
Syntaxbaum ergibt sich quasi natürlich dieses Vorgehen. Man arbeitet 
Ausdrücke von den Blättern des Baumes aus ab.

[Stefan F. (Gast)]

Dr. Sommer schrieb:
> definiere deine eigene Sprache.

Als hätten wir nicht schon genug. Alle 1-2 Jahre wird eine neue von der 
Presse angekündigt. Doch nur wenige haben so langfristig Erfolg, wie C.

[Rolf M. (rmagnus)]

Dr. Sommer schrieb:
> Stefanus F. schrieb:
>> Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese
>> Kontrolle leider nicht.
>
> Der GCC hat ein Attribut für printf-artige Funktionen, die entsprechend
> geprüft werden.

Beispiel aus der GCC-Doku:

extern int
my_printf (void *my_object, const char *my_format, ...)
      __attribute__ ((format (printf, 2, 3)));

> In C++ ist das mit std::cout viel besser - da wird immer automatisch
> richtig ausgegeben, abhängig vom tatsächlichen Typ. Leider sind die
> gängigen Implementationen davon nicht für uC geeignet.

Und das, obwohl das grundlegende Konzept von cout eigentlich deutlich 
besser für µCs geeignet ist, als printf.

x^y schrieb:
> Daher ein gut gemeinter Tipp: Konstanten immer durch passendes Postfix
> in den gewünschten Typ setzen und immer unsigned Typen verwenden sofern
> kein vorzeichenbehafteter Typ explizit notwendig ist.

Generell spricht aber auch manches dafür, es umgekehrt zu machen. Denn 
wenn man signed und unsigned mischt, gibt es noch ein paar andere 
Fallstricke. Ich versuche, für Bitgefummel immer unsigned zu verwenden, 
für alles andere normalerweise signed.

> Selbst harmlos aussehende Dinge wie
> int f(int n)
> {
>    return 1 << n;
> }
>
> sind mit signed Typen der absolute Horror, da gleich mehrfach
> undefiniertes Verhalten auftreten kann: n kann negativ sein =>
> undefiniert, n kann größer als int Bitlänge sein => undefiniert, 1
> (signed, daher Ausdruck int op int) kann ins Vorzeichen geschoben werden
> => undefiniert

Das meiste davon ist mit unsigned aber nicht besser. Wenn ich f(-1) 
aufrufe, ist n zwar nicht negativ, aber ein sehr großer positiver Wert, 
der devinitiv größer als die Bitlänge von int ist.

Frotho schrieb:
> M.K. B. schrieb:
>
>> Wenn man also die richtigen Warnings einschaltet, dann meckert der
>> Compiler auch.
>
> Noch einer. Was schreibt ihr alle für Miniprogramme?

Die schreiben keine "Miniprogramme", sondern einfach ordentlichen Code. 
Zu den Coding-Regeln gehört oft die Anforderung, dass das Programm 
komplett ohne Warnungen compilert werden muss (und das natürlich nicht 
durch Abschalten der Warnungen).

> Ich habe 1x die Warnings eingeschaltet und bin fast erschlagen worden von
> unused-parameter Warnings. Das brauche ich nicht. Jedenfalls nicht bei
> jedem Compilieren. Wenn ich fertig bin, ja, zum optimieren und für QS.

Umgekehrt solltest du es sehen. Die Warnungen sollen von Anfang an 
eingeschaltet sein, damit du gleich von vorn herein sauberen Code 
schreibst. Wenn du ein großes Programm komplett schreibst und dann erst 
ganz am Schluss die Warnungen einschaltest, ist natürlich klar, dass du 
davon praktisch erschlagen wirst.

> Aber nicht bei jedem Mal, da schwillt mir ja der Kopf.

Die Warnungen sind nicht dazu da, dich zu ärgern, sondern um dir 
potenzielle Probleme aufzuzeigen, die du natürlich auch beheben sollst.

> Habs gerade mal in ein Word doc kopiert: 16 A4-Seiten

Das ist ein Indiz dafür, dass mit deinem Code einiges nicht stimmt, 
nicht dafür, dass Warnungen nicht eingeschaltet werden sollten.

Dr. Sommer schrieb:
> Ungenutzte Parameter sind gerade in C ein Zeichen für schlechten Code
> (kaum Polymorphie).

Bei mir kommen sich durchaus öfters vor, nämlich dann, wenn man eine 
Funktion schreiben muss, die ein bestimmtes vordefiniertes Interface 
umsetzt. Beispielsweise Callback-Funktionen. Da braucht man aber nicht 
immer alle Parameter, die der Funktion übergeben werden.

> In C++ taucht so etwas häufiger auf, da kann man aber einfach den Namen
> des Parameters weglassen, dann verschwindet die Warnung.

Ja. Ich finde es schade, dass das in C nicht geht.

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Als hätten wir nicht schon genug.

Wenn seine neue Sprache so toll ist hat sie bestimmt Erfolg.

Rolf M. schrieb:
> Und das, obwohl das grundlegende Konzept von cout eigentlich deutlich
> besser für µCs geeignet ist, als printf.

Es ist leider nicht so leicht ohne dynamischen Speicher umsetzbar...

Rolf M. schrieb:
> Bei mir kommen sich durchaus öfters vor, nämlich dann, wenn man eine
> Funktion schreiben muss, die ein bestimmtes vordefiniertes Interface
> umsetzt

Ja, eigentlich nur dann ;-)

Rolf M. schrieb:
> Ja. Ich finde es schade, dass das in C nicht geht.

Wie so vieles... zum Glück gibt es kaum noch einen Grund für C.

Wenn ich eine fremde Bibliothek einbinde korrigiere ich manchmal erstmal 
ein paar Dutzend Stellen welche Warnungen produzieren. Geht aber leider 
nicht immer. Wenn man so etwas wie die stm32f1xx.h Header nutzt und beim 
g++ mit -Woldstyle-cast kompiliert hat man sonst Spaß ?

[Karl K. (karl2go)]

Sven P. schrieb:
> Kleiner Tipp: Es wäre in Delphi, TurboPascal und Visual Basic und Java
> semantisch genau so passiert.

Wohl kaum:

# [18] i := 30000 * 2;
  ldi  r20,96
  ldi  r21,-22
  mov  r19,r1
  mov  r18,r1

Womit 0x0000EA60 in i steht, was genau 60000 ist.

Mit i := a * b; und a, b als Konstanen genau das Gleiche. Mit a, b als 
uint16 wird daraus:

# Var a located in register r20
# [19] a := 30000;
  ldi  r20,48
  ldi  r21,117
# Var b located in register r22
# [20] b := 2;
  ldi  r22,2
  mov  r23,r1
# [22] i := a * b;
  mul  r20,r22
  movw  r24,r0
  mul  r21,r22
  add  r25,r0
  mul  r20,r23
  add  r25,r0
  clr  r1
  movw  r2,r24
  mov  r4,r1
  mov  r5,r1

Kommt auch korrekt 60000 raus.

[Falk B. (falk)]

Dr. Sommer schrieb:

> Wie so vieles... zum Glück gibt es kaum noch einen Grund für C.

Naja, C hat schon noch einen gehörigen Anteil am 
Programmiersprachenmarkt. Sei es der Linux-Kernel, verdammt viele 
Mikrocontroller und was weiß ich noch. Es ist nicht alles auf PC-Ebene 
und C++.

Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten 
von C herumgesprochen haben und man kann sie praktisch überaus passabel 
umschiffen.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

tsts..wie gut das ja nur Profis in C programmieren.
Daher war das ganz eindeutig Dein Fehler.
Das C einfach eine Anhäufung von Fehlern ist..neinein..das kann gar 
nicht sein..es immer immer der Programmierer schuld..ist doch völlig 
logisch..

[Sven P. (Gast)]

Karl K. schrieb:
> Sven P. schrieb:
>> Kleiner Tipp: Es wäre in Delphi, TurboPascal und Visual Basic und Java
>> semantisch genau so passiert.
>
> Wohl kaum:
[x] Du hast das Problem exakt überhaupt nicht verstanden.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

Q"Aber immerhin: es ist penibel und umfassend dokumentiert, was sie
tatsächlich machen."

heheh..ja genauso...:-) Alles in C ist dokumentiert..nur das es totaler 
murks ist haben sie vergessen im Klartext zu schreiben :-)

Und manche erkennen nur das was geschrieben steht..jedes C Buch sollte 
damit anfangen das C ein riesen Problem ist..

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

Autor: Sven P. (haku)
man merkt sofort er kennt diese Sprachen nicht, denn sonst wüsste er das 
es in Pascal NICHT passiert wäre!

[Tim T. (tim_taylor)]

Thomas M. schrieb:
> Autor: Sven P. (haku)
> man merkt sofort er kennt diese Sprachen nicht, denn sonst wüsste er das
> es in Pascal NICHT passiert wäre!

Sven P. schrieb:
> [x] Du hast das Problem exakt überhaupt nicht verstanden.

[x^y (Gast)]

Rolf M. schrieb:
> Das meiste davon ist mit unsigned aber nicht besser. Wenn ich f(-1)
> aufrufe, ist n zwar nicht negativ, aber ein sehr großer positiver Wert,
> der devinitiv größer als die Bitlänge von int ist.

Es gibt aber noch den gemeinen Fall "1 << 31" was für signed (int: 
32-bit) ebenfalls nicht definiert ist. Da lauert also ein recht 
bösartiger Bug selbst wenn man negative Werte und "n >= 32" abfängt, der 
nicht für jeden offensichtlich ist. Just dies war in einer SW die ich 
mal analysieren mußte tatsächlich fehlerursächlich, da damit ein Bittest 
gemacht wurde, der nicht wie erwartet funktionierte.

Man muss sich auch immer fragen: Was ist einfacher korrekt zu behandeln. 
Je komplizierter, desto mehr Fehler passieren. Da hat unsigned 
eigentlich immer die Nase vorn, da es von vorne herein weniger 
undefinierte Fälle gibt. Beispiel Addition: Bei unsigned einfach Modulo 
Bitlänge, bei signed undefiniert.

Für das gegebene Beispiel:

a) Unsigned

uint32_t f(uint32_t n)
{
   if (n >= 32U)
      return 0U;
   return 1U << n;
}

b) Signed

int32_t f(int32_t n)
{
   if ((n < 0) || (n >= 32))
      return 0;
   if (n == 31) /* shift 1 into sign bit */
      return INT32_MIN;
   return 1 << n;
}

Bei der Embedded Entwicklung habe ich ehrlich gesagt nur sporadisch 
Fälle, die tatsächlich signed Typen verlangen. Meist sind es entweder 
gleich float Typen oder aber unsigned Typen genügen. Float Typen haben 
natürlich ebenfalls viele Tücken, aber das steht auf einem anderen 
Blatt. Sobald man dann mit signed Typen konfrontiert ist, läßt man 
automatisch entsprechend größere Sorgfalt walten. Andernfalls hat man 
überall signed Typen und muss überall höllisch aufpassen.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    i_str :String[32];

begin
   i := 30000 * 2;
   
    writeln(inttoStr(i));
end.

geht unter Pascal fehlerfrei
https://rextester.com/l/pascal_online_compiler

[Alexander M. (a_lexander)]

Back to the roots....

Will mir einer vielleicht nochmals kurz erklären, warum ich bei

uint32_t a = 30000 * 2;

nicht 60000 bekomme, und es bei

uint32_t a = (uint16_t) 30000 * 2;

dann stimmt...

Was ist denn da der Unterschied für den Compiler zwischen den beiden 
Berechnungen?

[no c tomorrow, no sorrow (Gast)]

Falk B. schrieb:
> Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten
> von C herumgesprochen haben und man kann sie praktisch überaus passabel
> umschiffen.

Aber warum bitte schön kann man die Ecken und Kanten nicht glätten? 
Warum quält man Genarationen von Programmieren? Warum erzeugt man 
unnötige SW-Fehler, die nur dieser Bastelsprache anzuhängen sind.

Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit: 
Probleme verwalten und nicht die Ursachen beseitigen. :-<<<

[x^y (Gast)]

Rolf M. schrieb:
> Umgekehrt solltest du es sehen. Die Warnungen sollen von Anfang an
> eingeschaltet sein, damit du gleich von vorn herein sauberen Code
> schreibst. Wenn du ein großes Programm komplett schreibst und dann erst
> ganz am Schluss die Warnungen einschaltest, ist natürlich klar, dass du
> davon praktisch erschlagen wirst.

Sehe ich genauso und kann ich jedem nur dringend empfehlen. Von vorne 
herein Warnungen einschalten und deren Anzahl konsequent bei Null 
halten. Nur so springt einem eine neue Warnung direkt ins Auge wenn man 
etwas ändert.

Hatte auch schonmal so eine SW übernommen. Problem des Vorgängers: Zu 
viele Warnungen. Lösung des Vorgängers: Warnungen abschalten. Habe mich 
nicht schlecht gewundert, nach -Wall mit fast einer vierstelligen Anzahl 
Warnungen konfrontiert zu sein. Da waren Dinger drin a la "return" in 
Funktion mit Rückgabewert vergessen. Hat (ohne Compiler Optimierung) 
tatsächlich funktioniert, da Ergebnis zufällig in richtigem Register. 
Mit Compiler Optimierung hat's dann in der SW gekracht. Aber da war dann 
natürlich der Compiler dran schuld ("Compiler-Bug!") ...

[no c tomorrow, no sorrow (Gast)]

Alexander M. schrieb:
> Will mir einer vielleicht nochmals kurz erklären, warum ich bei
>
> uint32_t a = 30000 * 2;
>
> nicht 60000 bekomme

Und das ist der Beweis schlecht hin: Nach seitenlangen Posts konnte die 
Umschiffung der Ecke nicht vermittelt werden. :-<<<

Warum gibt es die Problematik überhaupt und warum wurde das nicht in 
C-Standard XYZ abgestellt?

[Emil (Gast)]

Signed und unsigned

[x^y (Gast)]

Alexander M. schrieb:
> Was ist denn da der Unterschied für den Compiler zwischen den beiden
> Berechnungen?

Der Autor hat zwei andere Fälle gehabt?! Im wesentlichen:

uint32_t i = 30000 * 2;

Ich unterstelle, der Autor arbeitet auf einer 16-Bit Plattform (int: 
16-Bit). Der Compiler sieht hier dann int16 * int16. In Bezug auf 
Integer/Integral-Promotion sind beide Seiten bereits int, d.h. es 
erfolgt kein implizites Casting der Operanden mehr. Wertebereich von 
int16 ist von -32768 bis +32767. Das echte Ergebnis 60000 paßt also 
nicht mehr in int16. C Standard sagt, Überlauf signed Multiplikation ist 
nicht definiert. Das Ergebnis von 60000 * 2 hängt damit von konkreter 
Architektur, Compiler und Flug der Schwalben ab. Was auch immer da raus 
kommt, wird dann konvertiert und in i gepackt. Fertig!

[x^y (Gast)]

x^y schrieb:
> Das Ergebnis von 60000 * 2 hängt

30000 * 2

[Stefan F. (Gast)]

Thomas M. schrieb:
> jedes C Buch sollte damit anfangen das C ein riesen Problem ist..

Wenn C ein riesen Problem wäre, würde es kaum genutzt werden, denn es 
gibt ja reichlich Alternativen. Das es unschöne Eigenschaften hat, will 
ich gar nicht abstreiten.

Mein Lieblingskäse stinkt. Mein liebster Tisch ist voller buchstäblicher 
Macken. Meine lieblings Schuhe sehen verschlissen aus. Mein 
Lieblings-Schraubendreher ist rostig.

Kennst du die Serie "Herr Rossi sucht sein Glück?". Sie verdeutlicht 
schön, dass man auf der permanenten Suche nach Perfektion seine Zeit 
vergeudet und die Dinge verpasst, die wirklich glücklich machen.

[Alexander M. (a_lexander)]

Okay habs (glaub) verstanden...

"Standard":
30000 * 2   --> int16_t * int16_6 => int16_t

Typcast uint16_t:
(uint16_t) 30000 * 2  --> uint16_t * int16_t => uint16_t

[Rufus Τ. F. (rufus)]

Alexander M. schrieb:
> Will mir einer vielleicht nochmals kurz erklären, warum ich bei
> uint32_t a = 30000 * 2;
> nicht 60000 bekomme, und es bei
>
> uint32_t a = (uint16_t) 30000 * 2;
> dann stimmt...

Das Prinzip ist einfach.

Was links vom Zuweisungsoperator steht, beeinflusst das, was rechts von 
ihm berechnet wird, nicht.

Berechnungen werden, sofern nicht explizit andere Typen angegeben sind, 
mit int durchgeführt.

Auf dem System, um das es hier geht, ist int ein 16-Bit-Datentyp.

Also ist 30000 * 2 negativ, denn die größte mit einem 16-Bit-Int 
darstellbare Zahl ist 32767.

Bei der nun erfolgenden Zuweisung wird das negative Ergebnis der 
vorzeichenlosen Zahl zugewiesen. Dabei wird zunächst das Ergebnis auf 
einen vorzeichenbehafteten Datentyp umgerechnet, der die gleiche Größe 
wie das Zuweisungsziel hat (also int32_t), und dann ohne weitere 
Konvertierung dieses Zwischenergebnis als vorzeichenlos behandelt.

Und das ist dann eine ziemlich große Zahll.


Im zweiten Fall wird durch den Typecast auf einen vorzeichenlosen 
Datentyp eine vorzeichenlose Berechnung durchgeführt. Das Ergebnis passt 
problemlos in den vorzeichenlosen 16-Bit-Datentyp, daher passiert bei 
der Zuweisung auch nichts ungewöhnliches.


Hier treten also drei Eigenschaften der Programmiersprache C auf, die 
anscheinend einige Leute massiv überfordern.

1) Bei einer Zuweisung eines Rechenergebnisses beeinflusst der Datentyp 
der Zuweisung die Berechnung nicht

2) Berechnungen erfolgen, sofern nicht durch Verwendung anderer 
Datentypen anders formuliert, immer mit dem nativen int-Datentyp des 
Compilers

3) Das Mischen von vorzeichenlosen und vorzeichenbehafteten Werten führt 
zu unerwarteten Ergebnissen, wenn dabei der ohne Vorzeichenwechsel 
verwendbare Wertebereich überschritten wird.

Alle diese drei Punkte sind elementares C, und nichts davon, was nicht 
in den ersten zwei Wochen der C-Erstsemstervorlesung oder in den ersten 
paar Kapiteln eines tauglichen Buches über die Programmiersprache 
behandelt werden sollte.

[Alexander M. (a_lexander)]

Es kann so einfach sein ;) ...
Danke!

[(prx) A. K. (prx)]

no c tomorrow, no sorrow schrieb:
> Aber warum bitte schön kann man die Ecken und Kanten nicht glätten?

Weil jede Änderung eines bestehenden Standards bestehende korrekte 
Programme aus der Kurve werfen kann, werden Standards meist nur 
erweitert. Bestehende korrekte Programme bleiben aber korrekt.

Eine Ausnahme: In 16-Bit K&R-C durfte 30000u * 1L als 30000uL oder 
30000L interpretiert werden, weil es im Standard weder als undefiniert 
noch als definiert vorkam. Das wurde in ANSI-C geklärt, potentiell zu 
Lasten bestehender Programme.

[x^y (Gast)]

no c tomorrow, no sorrow schrieb:
> Aber warum bitte schön kann man die Ecken und Kanten nicht glätten?
> Warum quält man Genarationen von Programmieren? Warum erzeugt man
> unnötige SW-Fehler, die nur dieser Bastelsprache anzuhängen sind.
>
> Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit:
> Probleme verwalten und nicht die Ursachen beseitigen. :-<<<

Wenn du die erschreckende Wahrheit hören möchtest:

Solange es Trottel gibt, die programmieren, wird es schlechte Software 
geben. Das ist kein Problem der Programmiersprache, sondern eine 
inhärente Eigenschaft des Homo Trottelensis. Sämtliche Versuche eine 
Heilung oder Genesung von Trotteln über die Medizin der 
Programmiersprache herbeizuführen sind bisher gescheitert. Das ist so 
als setzt jemand ohne Führerschein sein Auto an den nächsten Baum und 
erwartet zuverlässigere Autos. Trotzdem versucht man es immer wieder, 
nur um erneut festzustellen: es funktioniert nicht.

Man hat es mit Java versucht: Man hat gedacht, okay, explizites 
Speichermanagement, viel zu gefährlich, schießt sich jeder Trottel 
sofort mit ins Bein. Lösung: Nur noch Referenzen und Garbage Collection. 
Wenn irgendwas nicht geht, nicht mit undefinierten Ergebnissen 
weiterlaufen, sondern Exception werfen. War das Ergebnis dessen, dass 
nun jeder Trottel fehlerfreie Software schreiben kann? Nein! Man hat 
einige Fehlerursachen ausgeschlossen und teilweise nur gegen neue 
getauscht. Das Programm läuft zwar nicht mehr per Wildpointer Amok, kann 
aber trotzdem mit einer unbehandelten Exception und 3 Seiten Stacktrace 
abstürzen. Daneben rauft man sich den Kopf wie Garbage Collection 
effizient und ohne Zyklen zu machen ist und warum die Performance 
insgesamt so mies ist. Zum Glück hat man das JNI sodass man solche 
performancekritischen Teile dann auslagern kann - in C/C++ Code.

[(prx) A. K. (prx)]

Alexander M. schrieb:
> "Standard":
> 30000 * 2   --> int16_t * int16_6 => int16_t

Nur wenn sizeof(int16_t) == sizeof(int).
Präziser: int * int => int, egal wie gross.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

x^y
und genau wegen deiner Argumentation sind Atomkraftwerke auch so 
sicher..
Du hast es einfach nicht verstanden..und da es andere 
Programmiersprachen wie Pascal /Ada offenbar besser können , wäre es ja 
machbar.
aber Programmierer wie Du, die denken sie wären unfehlbar sind der Grund 
für Software voller Bugs:-(

[(prx) A. K. (prx)]

no c tomorrow, no sorrow schrieb:
> Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit:
> Probleme verwalten und nicht die Ursachen beseitigen. :-<<<

Um das mal auf einen anderen sehr bekannten Sachverhalt zu 
transponieren, hoffentlich ohne die üblichen Krieger auf den Plan zu 
rufen und ohne dabei den sachlichen Hintergrund zu bewerten:

Im Rahmen von Standards Probleme verwalten hiesse, alle bestehenden 
Dieselfahrzeuge auf ewig überall zuzulassen. Ursachen beseitigen hiesse, 
sie streckenweise von der Strasse zu verbannen.

Woran man erkennen kann, dass Änderungen, die bestehende Standards über 
den Haufen werfen, auch nicht alle glücklich machen.

[(prx) A. K. (prx)]

Thomas M. schrieb:
> Du hast es einfach nicht verstanden..und da es andere
> Programmiersprachen wie Pascal /Ada offenbar besser können , wäre es ja
> machbar.

Dann sollte man diese anderen Programmiersprachen eben auch verwenden. 
Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu 
verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und 
realer Maschinen definiert und in dieser Form realistisch einsetzbar 
ist. Was auf Ada zutrifft, auf Pascal aber m.W. nicht.

Für einen systematisch korrekten Ansatz einer universelle Sprache muss 
es eine formale Definition der Sprache geben, an die sich die Compiler 
zu halten haben. Ebenso wie die Programmierer. Der Ansatz "Compiler X 
macht es so, also stimmt es" ist systematisch unkorrekt.

[leo (Gast)]

no c tomorrow, no sorrow schrieb:
> Warum gibt es die Problematik überhaupt und warum wurde das nicht in
> C-Standard XYZ abgestellt?

[x] Du hast das Wort Standard verstanden.

Die M2-Schrauben sind mir zu klein und fehlertraechtig - warum werden 
die nicht doppelt so gross hergestellt.

Altes bestehendes Zeug ist mir Wurst und kann ruhig brechen.

leo

[Falk B. (falk)]

Alexander M. schrieb:
> Back to the roots....
>
> Will mir einer vielleicht nochmals kurz erklären, warum ich bei
>
> uint32_t a = 30000 * 2;

30000 wird als vorzeichenbehaftetet int Wert gerechnet, Wertebereich 
-32768 bis 32767. Überlauf bei  der Multiplikation.

> nicht 60000 bekomme, und es bei
>
> uint32_t a = (uint16_t) 30000 * 2;

uint16_t ist vorzeichenlos mit Werten von 0-65535, kein Überlauf bei der 
Multiplikation.

[Falk B. (falk)]

no c tomorrow, no sorrow schrieb:
> Falk B. schrieb:
>> Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten
>> von C herumgesprochen haben und man kann sie praktisch überaus passabel
>> umschiffen.
>
> Aber warum bitte schön kann man die Ecken und Kanten nicht glätten?
> Warum quält man Genarationen von Programmieren? Warum erzeugt man
> unnötige SW-Fehler, die nur dieser Bastelsprache anzuhängen sind.

Schon mal versucht, den Linksverkehr in England, Südafrika, Australien, 
Japan, Indien und sonstwo abzuschaffen?

[Stefan F. (Gast)]

A. K. schrieb:
> Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu
> verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und
> realer Maschinen definiert und in dieser Form realistisch einsetzbar
> ist.

Dann bist du bei Java. Aber es frisst Resourcen ohne Ende und eignet 
sich für µC daher nur sehr bedingt.

Java sollte alle Altlasten von C/C++ abschaffen, dafür hat es leider 
mindestens genau so viele neue Probleme geschaffen. Ausserdem dauerte es 
nach Veröffentlichung der Version 1.0 weitere 10 Jahre, bis die Sprache 
ernsthaft einsatzbereit wurde.

Was diese Integer-Berechnungen angeht verhält sich Java allerdings 
ziemlich genau so wie C. Aus irgendeinem Grund war man damals wohl 
sicher, dass so sein muss.

[(prx) A. K. (prx)]

x^y schrieb:
> Wertebereich von int16 ist von -32768 bis +32767.

Nur so nebenbei zur Zerstreuung: Zwar ist der Wertebereich von int16_t 
als -32768..+32767 definiert, der Wertebereich von int ist aber nur als 
mindestens -32767..+32767 definiert.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

Autor: leo (Gast)
aha..wo wäre denn die Gefahr wenn dieser Fehler behoben würde?!
Die Kompatibilität bliebe ja voll erhalten....

[(prx) A. K. (prx)]

Falk B. schrieb:
> Schon mal versucht, den Linksverkehr in England, Südafrika, Australien,
> Japan, Indien und sonstwo abzuschaffen?

... oder in Japan einheitlich entweder 50 oder 60 Hz. ;-)

[Sven P. (Gast)]

Stefanus F. schrieb:
> A. K. schrieb:
>> Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu
>> verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und
>> realer Maschinen definiert und in dieser Form realistisch einsetzbar
>> ist.
C ist doch ganz exakt das, was du beschreibst.

C ist maschinen- und compilerunabhängig beschrieben - ziemlich bündig 
und vollständig sogar. Und der C-Standard so formuliert, dass er sich 
gut auf realen Maschinen umsetzen lässt.

Einige Ecken und Kanten stammen ja genau dort her, u.a. die Bitbreiten 
von Ganzzahlen oder auch die Darstellung vorzeichenbehafteter Zahlen.

[Stefan F. (Gast)]

Die Technokraten dieses Landes könnten sich auch für die Abschaffung der 
Sommerzeit stark machen. Das würde mir viel mehr nützen, als dieser 
Integer Kinderkram.

Ich will gar nicht wissen, wie viele Entwickler schon Schande und Stress 
erleiden mussten, weil wie diese besch***** Uhr-Umstellungen haben. 
Dagegen hilft auch keine andere Programmiersprache.

[leo (Gast)]

Thomas M. schrieb:
> Autor: leo (Gast)
> aha..wo wäre denn die Gefahr wenn dieser Fehler behoben würde?!
> Die Kompatibilität bliebe ja voll erhalten....

Ich denke nicht, dass die Kompatibilität erhalten bliebe. Wo waere dann 
ein "Fix" des Problems.

leo

[(prx) A. K. (prx)]

Sven P. schrieb:
> Stefanus F. schrieb:
>> A. K. schrieb:
>>> Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu
>>> verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und
>>> realer Maschinen definiert und in dieser Form realistisch einsetzbar
>>> ist.
> C ist doch ganz exakt das, was du beschreibst.

Bitte Kontext beachten. Jenen Kontext, den Stefanus nicht mitzitierte. 
Mein Beitrag war eine Antwort auf die Vorzüge von Pascal und Ada. In 
Pascal existiert m.W. keine solche Definition.

[Einer K. (Gast)]

Stefanus F. schrieb:
> Wenn C ein riesen Problem wäre ...

Macht + Verantwortung --->> Disziplin

Alternativ:
Der Elefant im Porzellanladen


Ich empfehle ein schönes dickes und modernes C oder C++ Buch!
Und dann Seite für Seite auswendig lernen.

Das hilft nicht gegen Fußpilz, aber verschafft einen Überblick.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

n Pascal und Ada. In
Pascal existiert m.W. keine solche Definition.


jup, genau deshalb haben sich die Sprachen so gut weiterentwickeln 
können und sind zu keinem Flickenteppich wie C geworden.
Wenn irgendmöglich gibt es in Pascal die alte Variante, um dir 
Kompatibilität zu erhalten UND die neue.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"Ich empfehle ein schönes dickes und modernes C oder C++ Buch!
Und dann Seite für Seite auswendig lernen."

DARUM geht es!!
Macht man aber was falsch....
wenn man keine Fehler macht ist die Zuverlässigkeit der Sprache völlig 
wumpe!!

Aber NUR die User aus diesem Forum sind unfehlbar, es fehlt also an 
Programmieren!

[(prx) A. K. (prx)]

Thomas M. schrieb:
> "Ich empfehle ein schönes dickes und modernes C oder C++ Buch!
> Und dann Seite für Seite auswendig lernen."
>
> DARUM geht es!!

Jedes Detail auswendig lernen ist ein Weg. Das Wesen zu verstehen, die 
Grenzen zu kennen, und im konkreten Fall nachzuschlagen, ist ein 
anderer.

> Aber NUR die User aus diesem Forum sind unfehlbar, es fehlt also an
> Programmieren!

Du meinst also, es mangele an Fachkräften? ;-)

[leo (Gast)]

Thomas M. schrieb:
> n Pascal und Ada. In
> Pascal existiert m.W. keine solche Definition.

Genau, mit Ada waere das nicht passiert ...

"... Fehler bei der Typumwandlung gekommen. Als von Float nach Integer 
umgewandelt wurde und der Wert 32.768 erreichte, entstand ein 
Überlauf.[2] Dieser Überlauf hätte durch die verwendete 
Programmiersprache Ada eigentlich entdeckt und behandelt werden können. 
Diese Sicherheitsfunktionalität ließen die Verantwortlichen jedoch 
abschalten. Der Schaden betrug etwa 370 Millionen US-Dollar."

https://de.wikipedia.org/wiki/Liste_von_Programmfehlerbeispielen

Tl;dr 370 M$ Fehler.

BTW wo sind Pascal und Ada bei der µC-Programmierung, wenn sie denn so 
gut sind?

leo

[Oliver S. (oliverso)]

Thomas M. schrieb:
> geht unter Pascal fehlerfrei
> https://rextester.com/l/pascal_online_compiler

Sven P. schrieb:
> [x] Du hast das Problem exakt überhaupt nicht verstanden.


Oliver

[Daniel -. (root)]

in Go hat man sich dem angenommen und so gelöst
https://blog.golang.org/constants

die implizite Typwandlung integraler Typen in C und C++ ist wirklich
ein Misfeature

[(prx) A. K. (prx)]

Apropos Pascal: Was kommt bei
  maxint + maxint
und
  maxint * 2
raus, wenn man es auf der Wirth'schen Referenzmaschine exakt so ohne 
Optimierung berechnet?

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

teste es
//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    i_str :String[32];

begin
   i := 30000 * 2;

    writeln(inttoStr(i));
end.




geht unter Pascal fehlerfrei
https://rextester.com/l/pascal_online_compiler

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

aber wen interessiert es?
Wir reden hier von C aus dem Jahre 2019 und Pascal aus 2019
wen interessiert das Ref. Design aus 1970?!!?

Beide Sprachen haben sich wieterentwickelt, falls es dir entgangen ist, 
Pascal offenbar etwas meh r als C
Di Ref von Pascal bzw der Standard ist Delphi nocht PAscal 1.0

[Stefan (Gast)]

Habe getestet:

//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    a : Shortint;
    b : Shortint;
    i_str :String[32];

begin
   a := 30000;
   b := 2;
   i := a * b;

    writeln(inttoStr(i));
end.

==> 96

[Stefan F. (Gast)]

Kann es sein, dass die Integer Literale in Pascal einfach einen größeren 
Typ haben?

Laut 
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04619807 
table 2-5 ist der Datentyp von Integer Literalen Plattformabhängig.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

http://wiki.freepascal.org/Integer

[x^y (Gast)]

Jeder Entwickler macht sein Ding ohnehin so wie er/sie/es für richtig 
hält. Man kann sich also ganz entspannt zurücklehnen, durchatmen und 
sich einfach die passende Philosophie und Programmiersprache für die 
eigene Meinung suchen.

Eine US Firma die irgendwas im Neuland macht, sagt zur signed/unsigned 
Geschichte z.B.:
https://google.github.io/styleguide/cppguide.html#Integer_Types

The fact that unsigned arithmetic doesn't model the behavior of a simple integer, but is instead defined by the standard to model modular arithmetic (wrapping around on overflow/underflow), means that a significant class of bugs cannot be diagnosed by the compiler. In other cases, the defined behavior impedes optimization.

Sinngemäß: Vor dem Autofahren nicht zu trinken bedeutet, dass der 
Spurhalteassistent eine Reihe von Fehlern nicht wahrnimmt. Und betrunken 
fährt man meistens auch schneller.

Das unsigned Typen Optimierung behindern ist im Übrigen sogar Quatsch. 
Das Gegenteil ist auf den meisten Architekturen ist der Fall.


Beispiel: Ein Zero Extend ist in vielen Fällen bei unterschiedlicher 
Bitbreite unnötig, ein Sign Extent allerdings nicht.

// r0+r1: int32 + *int16
ldrh r0, [r2]
sxth r0, r0
add r0, r1

vs

// r0+r1: uint32 + *uint16
ldrh r0, [r2]
add r0, r1

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

@Stefan(Gast)
source.pas(12,9) Warning: range check error while evaluating constants 
(30000 must be between -128 and 127)

Du solltest wenn Du absichtlich sowas machst auch die Fehlermeldung 
veröffentlichen..

[Stefan F. (Gast)]

x^y schrieb:
> Man kann sich also ganz entspannt zurücklehnen, durchatmen und
> sich einfach die passende Philosophie und Programmiersprache für die
> eigene Meinung suchen.

Diesen Luxus haben die meisten nur im Hobby. Auf der Arbeit bestimmen 
andere, mit welchen Mitteln gearbeitet wird.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

und sorry, mein code war fehlerhaft wegen unnötiger Variable..
ic habe dein provokatives Beispiel korrigiert, allerdings verstehe  ich 
nicht, was das beweise soll, wenn ich absichtlich sowas mache?!
Es geht hier darum wie schnell versehentlich Fehler aufftreten können
//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    a : Shortint;
    b : Shortint;

begin
   a := 30000;
   b := 2;
   i := a * b;

    writeln(inttoStr(i));
end.

zum Onlinecompiler
https://rextester.com/l/pascal_online_compiler

[Einer K. (Gast)]

Stefanus F. schrieb:
> Auf der Arbeit bestimmen
> andere, mit welchen Mitteln gearbeitet wird.

Dann ist es Masochismus, dagegen angehen zu wollen.

So entstehen C-Hasser.

[(prx) A. K. (prx)]

x^y schrieb:
> Das unsigned Typen Optimierung behindern ist im Übrigen sogar Quatsch.
> Das Gegenteil ist auf den meisten Architekturen ist der Fall.

Undefiniertes Verhalten gibt dem Compiler mehr Möglichkeiten zur 
Optimierung, weil er weniger Rücksicht auf korrektes Verhalten nehmen 
muss. Das gab von einigen Jahren etwas Knatsch, als GCC deutlich 
offensiver mit diesem Thema umging und kommentarlos mit manch 
bestehendem nicht sauber definierten C Code in für den Programmierer 
leicht überraschender Weise umging.

TYPE i, n = parameter, sum = 0;
for (i = n; i < n+10; ++i)
  sum += 1;

Bei TYPE=int darf der Compiler davon ausgehen, dass die Schleife 
unabhängig von n exakt 10 Durchläufe hat und kann sie durch sum=10 
ersetzen. Bei TYPE=unsigned geht das nicht.

[(prx) A. K. (prx)]

Eine Abhandlung zum Overflow-Thema:
http://www.cs.utah.edu/~regehr/papers/overflow12.pdf

[Karl K. (karl2go)]

Rufus Τ. F. schrieb:
> Berechnungen werden, sofern nicht explizit andere Typen angegeben sind,
> mit int durchgeführt.

Das heisst, eine Konstante secsperday = 24  60  60 geht krachen, weil 
der C-Compiler bei int16 hängt, aber secsperday = 86400 geht?

Stefanus F. schrieb:
> Wenn C ein riesen Problem wäre, würde es kaum genutzt werden, denn es
> gibt ja reichlich Alternativen.

Neo ist auch effizienter als Qwerty, dennoch bekommst Du die Leute ums 
Verrecken nicht auf Neo. Weil Querty macht ja jeder.

leo schrieb:
> Tl;dr 370 M$ Fehler.

Weil man eine Software auf einem anderen Gerät als vorgesehen hat laufen 
lassen. Das liegt dann natürlich an der Programmiersprache.

leo schrieb:
> wo sind Pascal und Ada bei der µC-Programmierung, wenn sie denn so
> gut sind?

Die nehmen Leute, die damit mehr als ein paar blinkende LED zum laufen 
bringen. Die müssen das aber nicht jedem erzählen.

[(prx) A. K. (prx)]

Karl K. schrieb:
> aber secsperday = 86400 geht?

Richtig.

[Rolf M. (rmagnus)]

Dr. Sommer schrieb:
> Rolf M. schrieb:
>> Und das, obwohl das grundlegende Konzept von cout eigentlich deutlich
>> besser für µCs geeignet ist, als printf.
>
> Es ist leider nicht so leicht ohne dynamischen Speicher umsetzbar...

Genauso leicht oder schwer wie printf, hätt ich gesagt.

> Rolf M. schrieb:
>> Bei mir kommen sich durchaus öfters vor, nämlich dann, wenn man eine
>> Funktion schreiben muss, die ein bestimmtes vordefiniertes Interface
>> umsetzt
>
> Ja, eigentlich nur dann ;-)

Klar.

no c tomorrow, no sorrow schrieb:
> Falk B. schrieb:
>> Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten
>> von C herumgesprochen haben und man kann sie praktisch überaus passabel
>> umschiffen.
>
> Aber warum bitte schön kann man die Ecken und Kanten nicht glätten?

Das ist wie bei einem Sägeblatt. Das kann man auch "ohne Ecken und 
Kanten" bauen. Die Verletzungsgefahr sinkt dadurch deutlich, aber leider 
sägt es dann auch nicht mehr sonderlich effektiv.

> Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit:
> Probleme verwalten und nicht die Ursachen beseitigen. :-<<<

Die Ursachen sind die verschiedenen Architekturen, auf denen man in der 
selben Sprache effiziente Programm schreiben können soll. Also müsste 
man erstmal alle Plattformen bis auf eine abschaffen. Das würde die Zahl 
der Fallstricke in C enorm reduzieren.

x^y schrieb:
> Das Programm läuft zwar nicht mehr per Wildpointer Amok, kann
> aber trotzdem mit einer unbehandelten Exception und 3 Seiten Stacktrace
> abstürzen.

Ich muss immer wieder schmunzeln, wenn ein Java-Programm mal wieder mit 
einer "Nullpointer-Exception" abstürzt, wo die doch immer so stolz drauf 
sind, dass es da gar keine Pointer gibt, damit niemand einen solchen auf 
illegale Weise dereferenzieren kann.

A. K. schrieb:
> Thomas M. schrieb:
>> "Ich empfehle ein schönes dickes und modernes C oder C++ Buch!
>> Und dann Seite für Seite auswendig lernen."
>>
>> DARUM geht es!!
>
> Jedes Detail auswendig lernen ist ein Weg. Das Wesen zu verstehen, die
> Grenzen zu kennen, und im konkreten Fall nachzuschlagen, ist ein
> anderer.

Letzteres scheinen einige hier nicht zu können (oder nicht zu wollen). 
In so einem Fall bleibt dann nur der erste Weg, oder als Alternative, 
z.B. Bäcker zu werden.

[(prx) A. K. (prx)]

Stefanus F. schrieb:
> Auf der Arbeit bestimmen andere, mit welchen Mitteln gearbeitet wird.

Kenne ich auch anders. Programmentwickler entscheidet, ob Perl, Java, 
VB, PHP, ... Ist aber nicht im µC-Bereich.

[Alex D. (daum)]

Karl K. schrieb:
> Rufus Τ. F. schrieb:
>> Berechnungen werden, sofern nicht explizit andere Typen angegeben sind,
>> mit int durchgeführt.
>
> Das heisst, eine Konstante secsperday = 24  60  60 geht krachen, weil
> der C-Compiler bei int16 hängt, aber secsperday = 86400 geht?

Der Compiler hängt nicht bei int16, sondern int. Auf manchen Plattformen 
ist int eben nur 16bit breit, wie z.B. bei AVR.

Und außerdem gibt der Compiler eine Warnung aus, wenn diese 
eingeschaltet sind, was man sowieso immer machen sollte.

[W.S. (Gast)]

Rolf M. schrieb:
> Die Ursachen sind die verschiedenen Architekturen, auf denen man in der
> selben Sprache effiziente Programm schreiben können soll.

Eine derartige Argumentation ist heutzutage zu kurz gesprungen. Gerade 
in C hat es in der Vergangenheit immer wieder heftigste Widerstände 
gegen jegliche echte Modernisierung gegeben. Das ist der Grund - und 
deshalb ist auch heute noch immer nicht sauber festgenagelt, wieviele 
Bits die diversen Integertypen nun ganz genau zu haben haben, weswegen 
diese unsäglichen uint16_t und Konsorten aufgekommen sind.

Kurzum: Effizienz wird im Kopfe des Programmierers durch das Erfinden 
effizienter Algorithmen erzeugt, Optimierung kann mittlerweile auch der 
Compiler (und oftmals besser als ihr) und eine Sprache, wo man sich auf 
Dinge wie festgeschriebene Integergrößen verlassen kann, ist auch 
besser für effiziente Algorithmen.

Und nochwas:
Heutzutage wäre es eigentlich nicht zuviel verlangt, daß ein Compiler 
von sich aus jegliche konstanten Integer-Ausdrücke intern mit 
erheblicher Bitbreite (von mir aus 256 Bit) berechnet und erst danach 
schaut, in was für eine Variable das Ganze hineinpassen soll. 
Anschließend dann die Zuweisung oder Fehlermeldung. Damit wäre den 
Programmierern wirklich geholfen - egal, ob nun C oder Pascal oder Frust 
oder sonstwas. Und es wäre auch komplett rückwärtskompatibel. Und man 
könnte sich sowas wie (unsigned long) oder 4711UL sparen.

Aber an eine irgendwann mal erfolgende echte Modernisierung von C glaub 
ich nicht mehr.

W.S.

[Frank M. (ukw) (Moderator)]

W.S. schrieb:
> Heutzutage wäre es eigentlich nicht zuviel verlangt, daß ein Compiler
> von sich aus jegliche konstanten Integer-Ausdrücke intern mit
> erheblicher Bitbreite (von mir aus 256 Bit) berechnet und erst danach
> schaut, in was für eine Variable das Ganze hineinpassen soll.

Das ist kompletter Unsinn, denn dann könnte man sich auf nichts mehr 
verlassen.

Code 1:

    uint32_t i = 30000 * 2;

Code 2:

    int a = 30000;
    int b = 2;
    uint32_t i = a * b;

Wenn der Compiler Code 1 intern mit 256 Bit rechnen würde, kämen für 
beide Programmteile auf einem AVR unterschiedliche Ergebnisse raus.

Die Integer-Promotion ist dokumentiert und Bestandteil der Sprache. Wer 
sie nicht beherrscht, ist selber schuld.

[(prx) A. K. (prx)]

W.S. schrieb:
> Heutzutage wäre es eigentlich nicht zuviel verlangt, daß ein Compiler
> von sich aus jegliche konstanten Integer-Ausdrücke intern mit
> erheblicher Bitbreite (von mir aus 256 Bit) berechnet und erst danach
> schaut, in was für eine Variable das Ganze hineinpassen soll.

Eine künstliche Begrenzung von 256 Bits wäre unpassend. Hier wurde 
dieses Prinzip konsequenter gedacht: "As-if Infinitely Ranged Integer 
Model".
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019

[x^y (Gast)]

A. K. schrieb:
> TYPE i, n = parameter, sum = 0;
> for (i = n; i < n+10; ++i)
>   sum += 1;
>
> Bei TYPE=int darf der Compiler davon ausgehen, dass die Schleife
> unabhängig von n exakt 10 Durchläufe hat und kann sie durch sum=10
> ersetzen. Bei TYPE=unsigned geht das nicht.

Interessantes Beispiel! Danke :) Das ist ein plausibles Beispiel. Ich 
hatte jetzt mehr auf Maschinenebene als C Ebene gedacht.

Ich erinnere mich an zwei Fälle, wo der Compiler auch eine solche 
"undefined behavior" Optimierung ausgenutzt hat. In beiden waren die 
"Optimierungen" des Compilers allerdings fatal. Unsere Konsequenz war 
deshalb im Kodierstandard die Ausnutzung dieses Verhaltens sozusagen als 
"böse" zu verdammen. Ich werde jetzt nochmal sinnieren ob es Fälle gibt 
in denen das Verhalten auch positiv wäre.

Der Vollständigkeit halber hier der Fall:

Der Code stammt aus einem "Startup-Code in C weil Assembler ist doof" 
und realisiert eine Kopierschleife für Sections (".data" etc). Im Linker 
Script war eine spezielle Section angelegt, welche alle 
Kopieroperationen mit Quelle, Ziel und Anzahl Bytes beschrieben hat. Ich 
kann es hier nur sinngemäß wiedergeben:

struct SEC
{
   const void* src;
   void* trg;
   size_t size;
};
// defined in linker script pointing to start of special section
extern struct SEC table[1];

void process(void)
{
   int i;
   for (i = 0; (table[i].src != NULL) && (table[i].trg != NULL); ++i)
      memcpy(table[i].trg, table[i].src, table[i].size);
}

Für dieses Beispiel hat der Compiler tatsächlich eine Endlos-Schleife(!) 
um memcpy() generiert. Das ganze passierte bei der Umstellung des 
Compilers auf eine neue Version.

Nach unserem bestem Wissen war der Compiler dazu berechtigt unter 
Ausnutzung von "undefined behavior" Optimierungen. Da das Array aus 
Sicht des Compilers nur ein Element hat, kann er zunächst davon 
ausgehen, dass ein zweites Element nicht existiert. Man könnte dann 
denken er dürfte dann soetwas tun aber keine Endlosschleife:

void process(void)
{
   if ((table[0].src != NULL) && (table[0].trg != NULL))
      memcpy(table[0].trg, table[0].src, table[0].size);
}

Allerdings durfte er die Schleife ja nicht einfach ignorieren. Es bleibt 
je soetwas stehen:

for (i = 0; ; ++i)
   // something

Da für i keine Schleifenbedingung besteht, wurde natürlich noch i 
eingespart. Für den Compiler war nur ein Element erkennbar. Es blieb 
dann also übrig:

void process(void)
{
   if ((table[0].src != NULL) && (table[0].trg != NULL))
      for (;;)
         memcpy(table[0].trg, table[0].src, table[0].size);
}

Die Lektion daraus könnte auch lauten: Schreib den Startup Code in 
Assembler.

[c-hater (Gast)]

x^y schrieb:

> Das ist so, damit der Compiler effizienten Code erzeugen kann.

Wenn ich hocheffizienten Code will, schreibe ich ihn in Assembler. Da 
bin ich immer noch mindestens so gut wie der beste existierende 
C-Compiler, meist aber besser bis sogar sehr deutlich besser, letzteres 
allerdings oft nur mit "unfairen" Mitteln: ich benutze Eigenheiten des 
Zielsystems, die der Compiler schlicht (zumindest: noch) nicht kennt.

Für den normalen, performance-unkritischen Scheiß will ich aber eine 
Hochsprache, die einfach das tut, was ich hinschreibe. Das ist, was ich 
von einer Hochsprache verlangen würde, die diese Bezeichnung tatsächlich 
verdient. Die darf vom Design her nicht PRIMÄR darauf optimiert sein, 
das sich der Quelltext zu einem möglichst effizienten Compilat 
verarbeiten läßt, sondern darauf, dass sie immer etwas möglichst 
sinnvolles mit den gegebenen Anweisungen anfängt. Eine Hochsprache 
sollte eine Sprache sein, die es dem Programmierer leicht macht, nicht 
eine, die es dem Compiler leicht macht. Das sollte der Job einer 
Hochsprache sein. Will ich das nicht: dann nehme ich Assembler.

Bezogen auf Ausdrücke, die ausschließlich aus Literalen bestehen, würde 
das natürlich bedeuten, dass sie anfangs immer im jeweils 
kleinstmöglichen Typ dargestellt, aber auch immer automatisch 
"erweitert" werden. Und natürlich erwarte ich dann auch mindestens eine 
Warnung, wenn das Ergebnis eines solchen Ausdrucks zugewiesen wird und 
nicht in den Typ des Zuweisungsziels passt. Zumal dieses Szenario ganz 
offensichtlich rein garnix mit der Laufzeit-Effizienz zu schaffen hat, 
denn so ein Ausdruck läßt sich natürlich vollständig zur Compilezeit 
berechnen.

Mehr noch: ich würde dasselbe Verhalten auch für literale Teilausdrücke 
erwarten. Die Warnung hätte dann zu erfolgen, wenn sie mit einem Term 
verknüpft werden, der zur Compilezeit einen unbekannten Inhalt (aber 
natürlich einen bekannten Typ) hat. Das ist definitiv für einen Compiler 
möglich ohne jeden Impact auf die Laufzeit-Performance. Er kennt den 
Wert des literalen Ausdrucks, die Grenzen des Typs des zu verknüpfenden 
Terms und die anzuwendende Operation, er könnte also problemlos zur 
Compilezeit auf mögliche Probleme hinweisen. Auch wieder: ohne jeden 
Impact auf die Laufzeit-Performance.

Ja, das macht viel mehr Arbeit für die zwei, drei Dutzend Bauer eines 
Compilers. Aber spart viele Millionen Stunden Arbeitszeit für die 
Hunderttausende (oder auch Millionen) Benutzer des Compilers. Und 
verhindert viele Sicherheitslücken...

In C/C++ nicht realisiert. Ende, aus, eigentlich untauglich als 
"Hochsprache". Schlimm nur, dass man diesen Müll trotzdem so oft 
benutzen muss...

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

Ist C eine Hochsprache? Ich habe hier irgendwo ein Buch da werden PAscal 
und andere als solche bezeichnet, C aber eher als aufgebohrter 
Assembler...

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

dazu habe ich gerade das gefunden..
"C gilt im Vergleich zu BASIC oder PASCAL nicht als Hochsprache, sondern 
wird oft als Sprache "mittlerer Ebene" (middle-level language) 
eingestuft. "

http://c-buch.sommergut.de/Kapitel1/C-im-Vergleich-zu-anderen-Programmiersprachen.shtml


Bei D scheint es auch besser gelöst zu sein..nur in C wird gefrickelt
https://dlang.org/spec/type.html

[(prx) A. K. (prx)]

Hat eine Weile gedauert, aber nun sind wir wieder im gewohnten 
Fahrwasser. C-Hater ist auf Betriebstemperatur, Thomas hat auch sein 
Thema gefunden, und die Prügelei kann losgehen.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

das ist doch Quatsch...im Grunde wissen ja alle das 
Pascal/Delphi/Lazarus  die bessere Sprache ist.
Daher gibt es da doch gar keinen Streit;-) hehe

[(prx) A. K. (prx)]

So lange das halbwegs beim Thema Datentypen bleibt... Nun läuft es aber 
in die klassische Grundsatzdiskussion rein, ob man das Ei am dicken oder 
dünnen Ende aufschlägt. Da kann man auch gleich noch Windows vs Linux 
mit reinnehmen.

[K. S. (x_y)]

W.S. schrieb:
> Eine derartige Argumentation ist heutzutage zu kurz gesprungen. Gerade
> in C hat es in der Vergangenheit immer wieder heftigste Widerstände
> gegen jegliche echte Modernisierung gegeben.

Man kann in C genug organisch weiterentwickeln ohne dabei die 
grundlegende Intension von C über den Haufen zu werfen. Mir würden genug 
solcher Sachen einfallen. Das sind alles Dinge die Kosten keine 
Performance und sind Free Lunch und vor allem ändern nichts an der 
grundlegenden Intension der Sprache.

Ich denke die grundlegende Intension von C muss man schon akzeptieren. 
Wer alles komplett neu, anders und besser(TM) machen will muss seine 
eigene neue Sprache machen wie es jeder Info Student der was auf sich 
hält macht.

Nur ein Beispiel was man organisch weiterentwickeln kann:

Man kann mit Bitfeldern eigentlich sehr schön lesbar Registerzugriffe 
modellieren. Das ist komfortabl da man Bitpositionen, Bitlängen und mit 
AND/OR/NOT nichts händisch falsch machen kann. Quasi:

if (UART_S.bit.TXOF)
   UART_S.bit.TXOF = 1; // clear overflow

Diese Sache hat nur leider ein paar Schönheitsfehler:
- Auch ein "0-bit-writes ignored" Register wird immer ausgelesen, dann 
das Bit eingefügt und dann zurückgeschrieben. Das wäre aber nicht 
notwendig. Ein reines Schreiben würde ja genügen. Dies kann man aber 
nicht ausdrücken. Läßt man volatile weg, entfernt der Compiler womöglich 
den gesamten Schreibzugriff oder verschiebt ihn munter durch die ganze 
Funktion.
- Man kann mehrere Bitfeldzugriffe nicht kombinieren. Der Zugriff über 
diese Mechanik ist deshalb sehr ineffizient:

UART_S.bit.TXOF = 1;
UART_S.bit.RXOF = 1;

; load UART_S
; insert bit TXOF
; write-back UART_S
; load UART_S
; insert bit RXOF
; write-back UART_S
[code]

Soetwas in der Art wäre wünschenswert:

[code]
UART_S.bit.{.RXOF = 1, .TXOF = 1};

; load UART_S
; insert bit RXOF and TXOF
; write-back UART_S

uvm.

c-hater schrieb:
> Wenn ich hocheffizienten Code will, schreibe ich ihn in Assembler. Da
> bin ich immer noch mindestens so gut wie der beste existierende
> C-Compiler, meist aber besser bis sogar sehr deutlich besser, letzteres
> allerdings oft nur mit "unfairen" Mitteln: ich benutze Eigenheiten des
> Zielsystems, die der Compiler schlicht (zumindest: noch) nicht kennt.

Da würde ich meine Zweifel insofern anmelden, dass es nur noch mit 
unfairen Mitteln geht. Ich arbeite mit den neusten GCC Versionen für 
ARM, die optimieren für normale Funktionen unschlagbar gut. Gerade wenn 
Funktionen dann noch etwas größer sind steigt man mit händischer 
Optimierung nicht mehr durch. Und schließlich gibt's noch LTO. Da dreht 
der Compiler das gesamte Programm mit allen Modulen durch den Optimizer 
als wäre alles in einer Datei. Kein Mensch hat da eine Chance.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

Eigentlich ist es ja auch erschöpfend diskutiert..die C Leute 
verteidigen ihren Kack und schieben auf auf die Unfähigkeit der 
Nutzer..wie die Atomkraftbetreiber es auch Schicksal schieben oder sowas 
wenn was passiert.
Kommt halt immer nur drauf an wer weiter denkt und bei den C Menschen 
die nur in ihren 4 Wänden sitzen..naja reicht es auch durch soweit..

Komisch ist das die PAscal, Basic etc Leute kein Problem damit haben das 
man Fehler ihrer Liebslngssprache kritisiert und in C ist es wie einer 
Sekte..wenn der Herr(Die Iso Norm) es Dokumentiert hat..dann sei es..es 
zu kritisieren ist nicht gestattet..
DAS ist das einzige was nervt..jede Sprache hat ihre Vor und NAchteile 
und manchem wollen es absolut nicht akzeptieren

[K. S. (x_y)]

Nee, sowas wäre ja albern. Da würde man sich darüber streiten ob 
Rohrzange oder Schraubendreher das bessere Werkzeug ist. Es gibt für 
jedes Werkzeug eben die passende Anwendung.

[Einer K. (Gast)]

Thomas M. schrieb:
> zu kritisieren ist nicht gestattet..

Schwachfug!

Du kannst kritisieren, soviel du willst!

Nur glücklicher macht dich das nicht.
Und andere auch nicht.
An der Realität kratzt es ebenso nicht.

Kein Zugewinn zu erwarten!
Also kritisiere...

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"Nur glücklicher macht dich das nicht."
wie gesagt..

Akzeptiere die Dinge die du nicht ändern kannst. Der Herrgott wird dir 
den Weg weisen...


Und es gibt die Menschen die Dinge hinterfrage, ansprechen, diskutieren 
und so vielleicht eine Änderung bewirken..nennt sich aktiv gestalten..

Aber akzeptiert ihr mal...amen

[(prx) A. K. (prx)]

Das geht anders:

Gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann,
den Mut, Dinge zu ändern, die ich ändern kann,
und die Weisheit, das eine vom anderen zu unterscheiden.

[Karl K. (karl2go)]

Thomas M. schrieb:
> DAS ist das einzige was nervt..jede Sprache hat ihre Vor und NAchteile
> und manchem wollen es absolut nicht akzeptieren

Das ist aber eine spezielle Eigenheit dieses Forums. So wie man 
geschlachtet wird, wenn man im dt. Raspberry-Forum Python kritisiert.

Ich glaub das liegt daran, dass viele Leute die C* programmieren müssen 
eigentlich wissen wie scheisse das ist und wo es überall hängt, aber 
halt nix anderes können oder nix anderes dürfen. Und da werden dann die 
Unzulänglichkeiten als "muss so" deklariert.

[(prx) A. K. (prx)]

Karl K. schrieb:
> Ich glaub das liegt daran, dass viele Leute die C* programmieren müssen
> eigentlich wissen wie scheisse das ist und wo es überall hängt, aber
> halt nix anderes können oder nix anderes dürfen.

Oder weil es einfach überall da ist. Es geht oft weder darum, ob es gut 
ist ob man es mag oder ob man es darf, sondern dass man damit zu 
Lösungen kommen kann. Ich finde es weder gut, noch mag ich es, aber ich 
kenne es gut und nutze es wenn es passt - und anderes, wenn es nicht 
passt.

So einfach kann das sein. Ich mache weder Fetisch noch Hassobjekt 
daraus. Weshalb Leute so viel Emotionen reinstecken kann ich nicht 
nachvollziehen. Das ist ein Werkzeug, keine Freundin.

[Karl K. (karl2go)]

A. K. schrieb:
> Es geht oft weder darum, ob es gut
> ist ob man es mag oder ob man es darf, sondern dass man damit zu
> Lösungen kommen kann.

Aber ein Werkzeug, mit dem es keinen Spass macht zu arbeiten, ist 
irgendwie auch nervig.

Das ist wie der billige Bitsatz aus dem Wühltisch. Ja klar sind da alle 
möglichen Bits bei, und klar bekommt man damit auch die meisten 
Schrauben raus und rein.

Und irgendwann greift man doch zum besseren Bitsatz, und schon macht das 
Arbeiten Spass, die Bits greifen, die Schrauben werden nicht mehr 
ausgenüddelt, und man sucht nicht ständig nach dem einen Bit, der noch 
gerade so geht.

Und dann ärgert man sich allenfalls noch drüber, dass man nicht schon 
viel eher zum besseren Bitsatz gegriffen hat.

Zumal es bei vielen Alternativen zu C nichtmal eine Preisfrage ist wie 
beim Bitsatz.

[Rufus Τ. F. (rufus)]

Karl K. schrieb:
> Und irgendwann greift man doch zum besseren Bitsatz, und schon macht das
> Arbeiten Spass,

So ging es mir, als ich aufhörte, mich mit Pascal zu beschäftigen, und 
den ersten brauchbaren C-Compiler nutzen konnte. Das war Turbo-C 2.0, 
mit der exzellenten (deutschsprachigen) Dokumentation von Arne Schäpers.

[Karl K. (karl2go)]

Rufus Τ. F. schrieb:
> So ging es mir, als ich aufhörte, mich mit Pascal zu beschäftigen...

Wir hatten in der Schule bißchen TurboPascal, fakultativ. Und dann kam 
im Studium der Prof mit dem puren Pascal. Alles, was in TurboPascal 
darüber hinausging, war verboten. Das war so ein Krampf - zum 
Abgewöhnen.

Dadurch wurde mir Pascal über Jahre verleidet, und seitdem ich 
FreePascal entdeckt habe verfluche ich den Prof für die verlorene Zeit.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

genau das denke ich ist der Punkt!
So wird es vielen gehen..viele haben nur die Lehrsprache Pascal 
kennengelernt und meinen deshalb sie hätten total die Ahnung von Pascal 
und das es nichts taugt.
Aufwendige umfangreiche Prgramme wie der Altium Designer würde aber 
niemand in der Lehrsprache PAscal schreiben diese sind in Delphi! 
geschrieben.
Wenn jemand von den Vorzügen von apscalredet gilt das für Turbo Pascal 
ab V6 oder sowas.
Und nur die wenigsten die hier gegen Pascal reden, haben wirklich damit 
gearbeitet..wenn überhaupt mussten sie das gleiche wie Du in der Schule 
erleiden mit den Uraltversionen von Pascal.
Dank Freepascal / Lazarus gibt es auch was für ür die GUI Programmierung 
am PC wo man für C nur auch den C++ Bulider oder VC++ zurückgreifen 
könnte als Freeware!

[A. S. (Gast)]

x^y schrieb:
> Ich kann es hier nur sinngemäß wiedergeben:

Dein Fall scheint mir ein wenig zu seltsam. Kannst Du versuchen, die 
Originalzeilen zu finden bzw. Das Problem nachzustellen?

[A. S. (Gast)]

Karl K. schrieb:
> Ich glaub das liegt daran, dass viele Leute die C* programmieren müssen
> eigentlich wissen wie scheisse das ist und wo es überall hängt, aber
> halt nix anderes können oder nix anderes dürfen. Und da werden dann die
> Unzulänglichkeiten als "muss so" deklariert.

Auf der anderen Seite bietet C eine große Angriffsfläche.

Ein relativ eindeutiger Standard, der gut untersucht Tausende von 
bekannten Grenzfällen provoziert, die genüsslich ausgeweidet werden 
können.

Tausende Compiler, deren individuelle Fehler herangezogen werden können.

Historisch verschiedene "Default-rechenbreiten" die nativ erlaubt sind.

Die Freiheit (oder gar der Default), alle Warnungen zu ignorieren.

Bei meinen ersten Schritten in C dachte ich auch: wenn der Compiler 
weiss, dass hier die falsche klammer-zu ist ("meinten sie }"), warum 
korrigiert er es nicht gleich.

Aber dann bei jeder C-bash-aktiin hier zu hören:

 * Ja, bei Pascal-A nicht,, aber Pascal-B ....
 * Bei dieser Sprache mit GC,
 * Bei dieser Sprache mit dynamischer Speicherverwaltung,
 * Ich hab so viele Warnungen, ...

Nur als Beispiel unused Parameter, auch wenn der Frotho ja anscheinend 
nicht professionell mit C arbeitet:

Frotho schrieb:
> bin fast erschlagen worden von unused-parameter Warnings. Das brauche
> ich nicht. Jedenfalls nicht bei jedem Compilieren. Wenn ich fertig bin,

Wenn ich eine Funktion implementiere,, dann weiss ich doch, welche der 
vorgegebenen Parameter ich bei dieser Funktion brauche. Das Interface 
verlangt 7, 3 davon sind nur für Option X, die hier nicht behandelt 
wird. Also schreib ich doch in die erste Zeile zumindest einen 
Kommentar, dass Parameter e, f, g obsolete sind. Und statt Kommentar 
dann lieber (void) e; (void) f; (void) g;

Da gibt es zu keinem Zeitpunkt unnütze Warnungen. Im Gegenteil: der 
Compiler zeigt mir direkt an, dass ich a, b, c und noch nicht verwende.

[Stefan F. (Gast)]

Karl K. schrieb:
> Aber ein Werkzeug, mit dem es keinen Spass macht zu arbeiten, ist
> irgendwie auch nervig.

Da stimme ich zu. Dieser "Haken" ist allerdings nicht gross genug, um 
mich zu nerven.

[A. S. (Gast)]

Und nochmal zu Ada und Ariane:

> Dieser Überlauf hätte durch die verwendete Programmiersprache Ada eigentlich 
entdeckt und behandelt werden können.

Was ist das immer für ein Blödsinn? Ada hätte gewusst, welcher 
Integer-Wert besser gewesen wäre? Z.b. klippen bei 32767? Dann wäre der 
Flug korrekt weitergelaufen? Oder Ada hätte den Flug angehalten, eine 
Email an die Entwickler verschickt und auf einen Patch gewartet?

Exceptions sind eine tolle Sache, vor allem wenn ein Mensch davor sitzt: 
zu wenig Speicher? Besorg welchen, dann geht's weiter. Aber im autonomen 
System Antworten auf unvorhergesehene Fehler und Überläufe?

[Bernd K. (prof7bit)]

Frotho schrieb:
> [16 Seiten Warnungen]
> Wenn ich fertig bin, ja, zum optimieren und für QS.
> Aber nicht bei jedem Mal, da schwillt mir ja der Kopf.

Also mit anderen Worten: Dein Nachfolger soll sich irgendwann mal 
darum kümmern den von Dir geerbten hässlichen Dreckscode der über Jahre 
hinweg unkontrolliert vergammeln gelassen wurde endlich mal aufzuräumen 
und verwendbar zu machen. Dir als gottgleichem Schöpfer der kryptischen 
Schriften welcher 5cm über dem Boden schwebt können so niedrige Arbeiten 
wie sauberen Code zu schreiben nicht zugemutet werden sonst würde Dir 
der wertvolle Kopf explodieren.

Dir würd ich Beine machen, alter...

[Stefan F. (Gast)]

Bernd K. schrieb:
Harsche Kritik

Aber da ist was dran.

Frotho, ich rate Deiner Firma dringend, jemandem die Zeit zu geben, alle 
Warnungen zu 100% aufzuräumen und von da an ausschliesslich Code ohne 
Warnungen abzuliefern. Das sollte ein hartes Pflicht-Kriterium sein.

Code, der mit Warnungen compiliert, gilt als nicht lieferbar. Wir haben 
das bei uns in die Build Scripte integriert. Code mit Warnungen führt 
dazu, dass kein Package (*.deb, oder *.zip) gebaut wird.

Der Nutzen überwiegt eindeutig, da bin ich absolut sicher.

Falls dein Chef da anderer Meinung ist, darf er mich gerne mal als 
Consulter ausborgen, dann erkläre ich ihm das. Ich habe das schon in 
drei Firmen erfolgreich durchgezogen. Schicke mir ggf. eine persönliche 
Mail, dann bekommst du die Kontaktdaten meines Arbeitgebers.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

Es ist halt abzuwägen ob ich penibel alle halbe stunde und nach jedem 
Arbeitsschritt alles(Schreibtisch und Werkzeugkiste) aufräume, täglich, 
wöchentlich, oder nie.

Das hängt auch oft vom Zeitdruck ab. Klar das es irgendwann zeit kostet. 
Spätestens wenn man nichts mehr findet(länger sucht als effektiv 
arbeitet) oder nicht mehr durchblickt ist der Zeitgewinn der Schlamperei 
dahin. Spätestens dann ist es auch an der Zeit ein neues Auto zu 
bestellen und alles neu zu einzusortieren.
;)

Also Mittwoch ist es bei mir soweit, dann kommt der neue, der alte hat 
gut 100Tkm.

Namaste

[Falk B. (falk)]

Winfried J. schrieb:
> Es ist halt abzuwägen ob ich penibel alle halbe stunde und nach jedem
> Arbeitsschritt alles(Schreibtisch und Werkzeugkiste) aufräume, täglich,
> wöchentlich, oder nie.
>
> Das hängt auch oft vom Zeitdruck ab. Klar das es irgendwann zeit kostet.
> Spätestens wenn man nichts mehr findet(länger sucht als effektiv
> arbeitet) oder nicht mehr durchblickt ist der Zeitgewinn der Schlamperei
> dahin. Spätestens dann ist es auch an der Zeit ein neues Auto zu
> bestellen und alles neu zu einzusortieren.

Die schnellste und PREISWERTESTE Art etwas zu tun, ist es gleich richtig 
zu tun.

[Joe G. (feinmechaniker)]

Nur mal so als Test in MikroPascal PRO for AVR ;-)

program test;

Var
 i : Integer;
 a : Integer;
 b : Integer;

begin
  a := 30000;
  b := 2;
  i := a*b;
end.

Es kommt für i zuverlässig -5536 OHNE jegliche Compilerwarung raus.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

weil das nicht Teil dieser Diskussion ist..es geht um die Falle das
in C einen Fehler verursacht, was auf den ersten Blick unverständlich 
ist!
Was in Pascal/Delphi, Freepascal/Lazarus PAscal so funktioniert wie man 
es logisch erwartet gibt in C einen bösen Fehler!
Das von dir genannte Beispiel ist aber für jeden sofort ersichtlich,d as 
es schlicht grob falsch war..klar wäre es gut wenn auch sowas nicht 
durch den Compiler ginge, aber es ist klar ersichtlich, selbst für nicht 
C Programmierer

//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    a : Integer;
    b : Integer;
    
begin
   a := 30000;
   b := 2;
   i := a * b;

    writeln(inttoStr(i));
end.

zum Onlinecompiler
https://rextester.com/l/pascal_online_compiler

[Karl K. (karl2go)]

A. S. schrieb:
> Ada hätte gewusst, welcher
> Integer-Wert besser gewesen wäre? Z.b. klippen bei 32767? Dann wäre der
> Flug korrekt weitergelaufen?

In dem Fall - wenn ich mich recht an dazu Gelesenes erinnere - hätte die 
Bereichsüberschreitung dazu geführt, dass der Sensorwert als fehlerhaft 
gekennzeichnet wird und nicht genutzt wird. Der Flug wäre dann ohne 
diesen Sensorwert weitergegangen, er war redundant.

Mache ich bei meiner Heizungssteuerung auch so: Ist ein Temperatursensor 
nicht verfügbar oder liefert offenbar unplausible Werte (Kabelbruch, 
Kurzschluss), wird sein Wert als ungültig verworfen und das Programm 
fährt mit einem Standardwert weiter. Zum Beispiel ohne Aussenfühler wird 
eben nicht außentemperaturgeführte Heizkurve gefahren, sondern konstante 
Vorlauftemperatur.

Aber lustig ist: Es wird immer wieder dieses Beispiel dafür gebracht, 
dass Ada ja auch Fehler zulässt. Und dabei geht es in diesem Beispiel 
nun gerade darum, dass die Fehler mit Ada hätten vermieden werden 
können.

Andererseits werden seit Jahren Mrd durch C-Programme vernichtet...

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

auch sowas verursacht in Pascal einen Fehler

  i := (30000 * 2);

source.pas(13,9) Warning: range check error while evaluating constants 
(60000 must be between -32768 and 32767)

ind D ebenfalls! wenn z.B. als Short definiert..der Int ist dort 
erheblich größer, zumindest gibt es mit Int keine Fehler

    i = 30000 * 2;

source_file.d(12): Error: cannot implicitly convert expression (60000) 
of type int to short

in C kommt raus..
-5536

Fehlermeldung von C....KEINE!

[Karl K. (karl2go)]

Thomas M. schrieb:
> Dank Freepascal / Lazarus gibt es auch was für ür die GUI Programmierung
> am PC wo man für C nur auch den C++ Bulider oder VC++ zurückgreifen
> könnte als Freeware!

Naja, es gibt schon auch noch PureBasic, was eine ordentliche und vor 
allem schlanke Gui hinbekommt, zumindest unter Windows.

Und es gibt Qt, welches auch unter FreePascal geht. Allerdings ist das 
Signal-Slot-Konzept unter C so nervig, bis ich da die ganzen Slots für 
meine Gui definiert habe, ist das Programm unter Pascal schon fertig.

Qt verwende ich nicht wegen der nervigen Lib-Verwaltung. Ich kann auf 
einem Kundenrechner nicht mal schnell die Qt-Libs installieren, nur weil 
mein Terminal die für die Gui braucht.

Also ja, FreePascal ist momentan die Sprache der Wahl vom AVR über 
Raspberry Pi bis Windows.

[Stefan F. (Gast)]

Thomas M. schrieb:
> Das von dir genannte Beispiel ist aber für jeden sofort ersichtlich

Auch der ursprüngliche gemeldete Fall in C war zumindest für mich sofort 
ersichtlich, denn ich habe gelernt, dass Numerische Literale vom Typ 
Integer sind, solange sie in einen Integer passen.

Das ist eine simple Regel, die man sich leicht merken kann. Wer das 
nicht schafft, ist für den Job als Programmierer ungeeignet.

Die anderen, die das als Hobby machen und darüber stolpern, fragen hier 
nach, bekommen ihre erklärende Antwort, und gut ist.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

Falk B. schrieb:
> Die schnellste und PREISWERTESTE Art etwas zu tun, ist es gleich richtig
> zu tun.

Richtig, im Feld aber ohne Vorabkenntnis des Fehlers nicht immer 
realisierbar.
Namaste

[Stefan F. (Gast)]

Karl K. schrieb:
> Andererseits werden seit Jahren Mrd durch C-Programme vernichtet...

Und es werden noch viel mehr Mrd durch C verdient! Ein bisschen 
Verschnitt ist immer. Menschen sind unperfekt, daran können wir nicht 
ändern. Daher sind auch unsere Produkte unperfekt. Wer das nicht 
akzeptieren kann, hat ein ernsthaftes Problem mit allem.

[Stefan F. (Gast)]

Karl K. schrieb:
> Qt verwende ich nicht wegen der nervigen Lib-Verwaltung. Ich kann auf
> einem Kundenrechner nicht mal schnell die Qt-Libs installieren, nur weil
> mein Terminal die für die Gui braucht.

Liefere sie doch einfach mit, im selben Verzeichnis, wo auch die *.exe 
liegt. Ich sehe da kein Problem.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

oder er verzichtet drauf, benutzt Pascal und der Kunde muss abosolut gar 
nicht installieren...sondern einfach nur benutzen!

[Stefan F. (Gast)]

Thomas M. schrieb:
> oder er verzichtet drauf, benutzt Pascal und der Kunde muss
> abosolut gar
> nicht installieren...sondern einfach nur benutzen!

So ein Quatsch. Es muss immer die Anwendung und ihre Libraries 
installiert oder zumindest irgendwohin kopiert werden. Wenn du eine 
Anwendung statisch linkst, sind die Libraries mit in der *.exe Datei 
drin. Das kann C/C++ allerdings ebenso.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"für mich sofort
ersichtlich, denn ich habe gelernt, dass Numerische Literale vom Typ "

Du hast das Problem nicht verstanden.
Es geht darum das Fehler passieren und diese in C unglaublich oft 
unbemerkt bleiben!
Wie auch an den Pascal Beispielen gezeigt, kann man das auch in Pascal 
schaffen, aber in D wird es schon echt schwer


Es geht darum das Menschen Fehler machen!
Wenn jemand schreibt
"Wer das
nicht schafft, ist für den Job als Programmierer ungeeignet."


sollte seien Jobwahl noch mal überdenken oder wirklich nur unwichtige 
Programme schreiben, einem´n mit so einer Einstellung kann man nicht im 
KFZ Bereich oder Luftfahrt gebrauchen!

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Code, der mit Warnungen compiliert, gilt als nicht lieferbar.

Praktische Frage: Wie gehst Du mit sowas um?

[code    Rxbuf[rxwrite] := Char(tchr);  // Daten in Rx Buffer
    Inc(rxwrite);
    if rxwrite >= Crxlen then begin
      rxwrite := 0;
    end;[/code]

Ein Ringbuffer für den Uart Empfänger am AVR. Der Schreibzeiger rxwrite 
ist 1 Byte (uint8), die Buffergröße Crxlen ist 256. Gibt richtig eine 
Warnung: Unreachable Code. Und die if-Bedingung wird wegoptimiert.

Ich will das aber dennoch drinlassen, weil Crxlen auch kleiner als 256 
definiert sein kann.

Ignorieren, denn der Fehler ist ja offensichtlich nicht relevant? Per 
#ifdef ausklammern?

Der Code ist an der Stelle einfach effizient und würde durch rxwrite als 
uint16 nur aufgebläht.

[Rufus Τ. F. (rufus)]

Thomas M. schrieb:
> oder er verzichtet drauf, benutzt Pascal und der Kunde muss abosolut gar
> nicht installieren.

Oder er lernt, mit seinem Werkzeug umzugehen. Dann muss der Kunde auch 
bei Verwendung eines C- oder C++-Compilers nichts zusätzlich 
installieren.

Dein Gekreische spiegelt nur Deine Ahnungslosigkeit und Deine 
Lernresistenz wider.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"So ein Quatsch. Es muss immer die Anwendung und ihre Libraries
installiert oder zumindest irgendwohin kopiert werden"
Quack..starte es doch einfach vom Stick!


Aber egal..wir sind damit weg vom Thema

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"Dein Gekreische spiegelt nur Deine Ahnungslosigkeit und Deine
Lernresistenz wider."

Aha, und Dieser Satz zeigt mal wieder DEiNE Unfähigkeit schlichtend als 
Mod zu arbeiten sondern lieber rumtrampeln wie ein Elch in Trudes Shop
Und auch für Dich gilt, das gehört nicht mehr zum eigentlichen Thema.
Ich wiederhole mich..Du bist hier als Mod offenbar falsch! Deine Aufgabe 
ist es nicht die Stimmung anzuheizen

[A. S. (Gast)]

Karl K. schrieb:
> Ist ein Temperatursensor
> nicht verfügbar oder liefert offenbar unplausible Werte (Kabelbruch,
> Kurzschluss), wird sein Wert als ungültig verworfen und das Programm
> fährt mit einem Standardwert weiter. Zum Beispiel ohne Aussenfühler wird
> eben nicht außentemperaturgeführte Heizkurve gefahren, sondern konstante
> Vorlauftemperatur.

Das ist richtig, und in meinem Fall auch tägliches Brot. Ein Problem wie 
bei Ariane 5 (https://de.wikipedia.org/wiki/Ariane_V88#Verlauf), also 
Overflow bei Float nach int wird bei uns praktisch immer explizit 
behandelt, z.B. durch Clippende Funktionen, weil man nur an genau der 
Stelle weiss, was man denn wirklich machen will.

Mein Problem ist, dass die Verfechter von Exceptions und ADA an jeder 
Stelle wie selbstverständlich davon ausgehen, dass der Fehler damit 
adäquat behandelt worden wäre. Ich sehe in der Praxis bei uns dagegen, 
dass Treiberprogrammierer damit nur ihre Verantwortung abgeben und das 
nach 3 Folge-Exceptions (bzw. Esdkalierungen) niemand mehr 
verantwortlich ist, weil "das ja niemand ahnen konnte".

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Menschen sind unperfekt, daran können wir nicht
> ändern.

Ja, das finde ich auch lustig: Wenn man auf die Probleme in C mit 
Typecast, Bufferüberlauf... hinweist, heisst es ja regelmäßig "Wenn man 
die Warnungen anschaltet, kann das nicht passieren, der Compiler weist 
einen darauf hin."

Nur passieren diese Fehler ständig, werden von Trojanern ausgenutzt um 
über zu lange Strings in HTML-Adressen, angehängte Daten an Bilder und 
Videos... Bufferüberläufe zu provozieren und Schadcode einzuschleusen.

Also entweder sind diese Programmierer, denen das passiert zu doof die 
Compilerwarnungen zu lesen, oder sie sind so überheblich, dass sie 
glaube sie ignorieren zu können.

Sonst würde das ja nicht passieren. Oder?

[Oliver P. (Gast)]

Thomas M. schrieb:
> "Dein Gekreische spiegelt nur Deine Ahnungslosigkeit und Deine
> Lernresistenz wider."

Kannst du bitte die Zitierfunktion benutzen? Sonst muss man erahnen wen 
du meinst und man verliert den Überblick leicht.

Und es entstehen falsche Zitate, siehe oben...

Danke.

[(prx) A. K. (prx)]

@Thomas: Auch ein Moderator darf eine Meinung haben, und das muss nicht 
zwingend eine moderate sein. Dem Forum fehlt aber die Möglichkeit, auch 
mal ohne "Moderator" Schild auftreten zu können.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

er darf eine Meinung haben, aber wie er diese Äußert sollte wohl 
überlegt sein, da der Ton bislang eigentlich erträglich war und von 
recht wenigen provokationen.

Aber er ist mal ieder ein Paradebeispiel wie man es NICHT macht!!
Sonst ist logisch, das sich der Angegriffene rechtfertig und die ganze 
Diskussion aus dem Ruder läuft..sollte man als fähiger Mod wissen..wenn 
er aber so in C porgrammiert wie er hier moderieert..na danke,...

[Stefan F. (Gast)]

Karl K. schrieb:
> Praktische Frage: Wie gehst Du mit sowas um?

Das macht man in C so:

#define CRXLEN 256
char rxbuf[CRXLEN];
int rxwrite=0;

void writeToBuf(char c)
{
    rxbuf[rxwrite++]=c;
    if (rxwrite>=CRXLEN)
    {
        rxwrite=0;
    }
}

Wo ist jetzt dein Problem mit "unreachable code"?

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Wenn du eine
> Anwendung statisch linkst, sind die Libraries mit in der *.exe Datei
> drin. Das kann C/C++ allerdings ebenso.

Ja, aber bei Qt darfst Du das halt nicht, wenn Du die GPL beachtest. 
Zumindest hab ich das so verstanden, als ich mir das damals angeschaut 
habe. Da muss die Qt-Lib dynamisch gelinkt und immer mitgeliefert werden 
oder auf dem System installiert sein.

Stefanus F. schrieb:
> Liefere sie doch einfach mit, im selben Verzeichnis, wo auch die *.exe
> liegt. Ich sehe da kein Problem.

Die exe war in dem Fall ein Uart-Terminal, welches aus einer einzigen 
exe besteht und vom Stick läuft, ohne irgendwas am System zu verändern. 
Und wenn man dann vergisst die Qt-Lib mit auf den Stick zu kopieren... 
sucht man halt erstmal das gute alte BrayTerm raus.

Da Qt nicht zwingend erforderlich ist, geht es ohne einfacher.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

Dein Beispiel ist ja logisch, sinnvoll udn wohl auch üblich..nicht nur 
in C aber diese Konstrukt wendet man nicht für jeden Firlefanz an, und 
dann passiert eben so ein Fehler

[Stefan F. (Gast)]

Karl K. schrieb:
> Ja, aber bei Qt darfst Du das halt nicht, wenn Du die GPL beachtest.

Richtig. Na und?

Es ging darum, die Sprache bzw die Funktionalität des Frameworks zu 
kritisieren. Jetzt sind wir beim Lizenzmodell angekommen. C ist also 
kacke weil Qt ohne Lizenzkosten nur dynamisch gelinkt werden darf. 
Ernsthaft?

> Und wenn man dann vergisst die Qt-Lib mit auf den Stick zu kopieren...

Und wenn man vergisst zu atmen, bekommt man keine Luft mehr.

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Wo ist jetzt dein Problem mit "unreachable code"?

Ja Kunststück, wenn ich rxwrite als uint16 definiere geht das in Pascal 
auch.

Ich bin aber auf dem AVR = 8-Bitter und hätte rxwrite gern als uint8. 
Für alle Crxlen < 256 wird rxwrite in der if genullt, für Crxlen läuft 
rxwrite von alleine um.

Es ist ja nicht allein, dass uint16 ein Byte mehr im SRAM benötigt, alle 
Vergleiche und Berechnungen werden dann auch mit 16bit statt 8bit 
durchgeführt.

Uuund: Ich müsste es kapseln, weil ein 2-Byte Zugriff durch den 
Interrupt unterbrochen werden kann.

[A. S. (Gast)]

Karl K. schrieb:
> Stefanus F. schrieb:
>> Code, der mit Warnungen compiliert, gilt als nicht lieferbar.
>
> Praktische Frage: Wie gehst Du mit sowas um?
>
>

    Rxbuf[rxwrite] := Char(tchr);  // Daten in Rx Buffer
>     Inc(rxwrite);
>     if rxwrite >= Crxlen then begin
>       rxwrite := 0;
>     end;

>
> Ein Ringbuffer für den Uart Empfänger am AVR. Der Schreibzeiger rxwrite
> ist 1 Byte (uint8), die Buffergröße Crxlen ist 256. Gibt richtig eine
> Warnung: Unreachable Code. Und die if-Bedingung wird wegoptimiert.
>
> Ich will das aber dennoch drinlassen, weil Crxlen auch kleiner als 256
> definiert sein kann.
>
> Ignorieren, denn der Fehler ist ja offensichtlich nicht relevant? Per
> #ifdef ausklammern?
>
> Der Code ist an der Stelle einfach effizient und würde durch rxwrite als
> uint16 nur aufgebläht.

Ja, das ist ein echtes Problem. Und ja, für solche Fälle haben wir nur 
schlechte Workarounds, #ifdefs oder Warnung lokal ausschalten.

Gut, wir würden sowas in einem "spezielles" Inc verstecken, aber so wie 
oben, bleibt es ein Dilemma.

Schaltest Du die Warnung aus, dann warnt der Compiler auch nicht, wenn 
ein hinzugefügter "Überlaufzähler" auch nicht incrementiert wird. Oder 
eine Toggle-LED zur Diagnose.

Und #ifdef für den Code wäre noch übler, da redundant (unwartbar).

[Karl K. (karl2go)]

Stefanus F. schrieb:
> C ist also
> kacke weil Qt ohne Lizenzkosten nur dynamisch gelinkt werden darf.

Das hast Du jetzt behauptet. Ich habe nur geschrieben, dass ich Qt aus 
diesem Grund - und weil ich es nicht brauche - nicht verwende. Auch 
unter Pascal, denn da besteht genau das gleiche Problem, dass man die 
Qt-Libs braucht, wenn die Exe laufen soll.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

wieso landen solche Diskussionen eigentlich immer unter in Offtopic?

[Stefan F. (Gast)]

Karl K. schrieb:
> Ich bin aber auf dem AVR = 8-Bitter und hätte rxwrite gern als uint8.

Na und? Mach das doch mal. Auch dann bekommst du keine unerwünschte 
Warnung. Ich hab's gerade versucht.

Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar 
nicht kennst.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar
nicht kennst."
Du meinst wie die C Leute bei Pascal  Delphi Lazarus?
Die ja nur die Schulversion 1.0 kennen?
Deshalb versucht man ja sachlich zu diskutieren um sich auszutauschen

[Stefan F. (Gast)]

Thomas M. schrieb:
> Du meinst wie die C Leute bei Pascal  Delphi Lazarus?

Ich kenne jedenfalls die Schulversion von Pascal, sowie Borland Pascal 
mit Turbo Vision und Delphi bis Windows 98. So ganz im dunklen tappe ich 
also nicht. Ich habe im Übrigen nicht über Pascal gemeckert.

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar
> nicht kennst.

Bist Du irgendwo falsch abgebogen? Es geht bei meiner Frage überhaupt 
nicht um C oder ob C das hier besser macht.

Ich habe lediglich auf die Aussage "Projekte müssen ohne Warnungen 
kompilieren" gefragt, wie man mit so einem Fall umgeht. Weil ich genau 
der Meinung bin und gern diese Warnung weg hätte, ohne die Variablen von 
8 auf 16 Bit aufzublasen.

Das hat überhaupt nichts damit zu tun, ob C das besser kann. Und wenn Du 
mal in das Kompilat schaust, wirst Du merken, dass C hier einfach die 
if-Abfrage wegoptimiert, weil unreachable code. Pascal optimiert die 
if-Abfrage auch weg, weil unreachable code. In beiden Fällen richtig, 
nur das Pascal halt die Warnung schmeisst, die ich gern weg hätte.

Periphär würde mich jetzt interessieren, warum C an der Stelle nicht 
warnt. Aber das war nicht Grund meiner Frage.

[Uhu U. (uhu)]

Statt hier eure Zeit mit dem Streit um Kaisers Bart zu verplempern, 
könntet ihr euch auch in C einarbeiten - davon habt ihr auf Dauer 
sicherlich mehr…

[Stefan F. (Gast)]

Karl K. schrieb:
> Ich habe lediglich auf die Aussage "Projekte müssen ohne Warnungen
> kompilieren" gefragt, wie man mit so einem Fall umgeht.
>  Weil ich ... gern diese Warnung weg hätte

Da kommt doch jetzt schon keine Warnung!

> dass C hier einfach die if-Abfrage wegoptimiert, weil unreachable code.

Das ist auch gut so. Ich verstehe nicht, warum du diese Eigenschaft des 
Compilers jetzt plötzlich bemängelst.

Wenn der Code durch andere Puffergrösse erreichbar gemacht wird, wird 
auch nichts weg optimiert.

> Periphär würde mich jetzt interessieren, warum
> C an der Stelle nicht warnt.

Weil es dort nichts zu warnen gibt. An dem Code ist überhaupt nichts 
fragwürdiges.

Wenn du erweiterte Warnungen für Stellen haben möchtest, wo der 
Programmierer eventuell etwas übersehen hat, dann benutze lint. In 
vielen Entwicklungsumgebungen ist dieses Tool bereits standardmässig 
integriert und aktiv. Zum Beispiel in Qt.

[Daniel -. (root)]

> Periphär würde mich jetzt interessieren, warum C an der Stelle nicht
> warnt. Aber das war nicht Grund meiner Frage.

kann es sein, dass dir der Unterschied zwischen der Sprache und der 
Implementierung der Sprache nicht klar ist?

meines Wissens schreibt der Standard nicht vor, wann welche Warnung
auszugeben ist. Die Implementierungen stehen bei Warnungen in Konkurenz
zueinander, möglichst gute und verständliche Warnungen zu geben

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Da kommt doch jetzt schon keine Warnung!

Auch wenn es anscheinend über Deinen Horizont geht:

ES GEHT NICHT UM C!

Es gibt auch noch andere Sprachen auf der Welt.

[Stefan F. (Gast)]

Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht.

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht.

Dann bleib halt in Deiner kleinen C-Welt. NMP.

[Stefan F. (Gast)]

Karl K. schrieb:
> Dann bleib halt in Deiner kleinen C-Welt. NMP.

C füllt in meiner Welt nur einen winzig kleinen Teil aus. Ich arbeite 
ganz woanders und ich habe viele Programmiersprachen kommerziell 
eingesetzt. Da war lange Zeit auch dein geliebtes Pascal bei.

Ich liebe inzwischen eine Frau.

[Rufus Τ. F. (rufus)]

Stefanus F. schrieb:
> Ich liebe inzwischen eine Frau.

Damit hast Du diese reichlich überflüssige Diskussion eigentlich sehr, 
sehr schön auf den Punkt gebracht.

Menschen sind viel wichtiger als Programmiersprachen.

[(prx) A. K. (prx)]

Thomas M. schrieb:
> wieso landen solche Diskussionen eigentlich immer unter in Offtopic?

Um c-hater kalt zu stellen.

[Rolf M. (rmagnus)]

Karl K. schrieb:
> Stefanus F. schrieb:
>> Wenn du eine
>> Anwendung statisch linkst, sind die Libraries mit in der *.exe Datei
>> drin. Das kann C/C++ allerdings ebenso.
>
> Ja, aber bei Qt darfst Du das halt nicht, wenn Du die GPL beachtest.

Darfst du schon. Dein Programm muss dann halt auch unter GPL stehen, 
oder du musst eine kommerzielle Lizenz kaufen.

> Zumindest hab ich das so verstanden, als ich mir das damals angeschaut
> habe. Da muss die Qt-Lib dynamisch gelinkt und immer mitgeliefert werden
> oder auf dem System installiert sein.

Ich sehe jetzt nicht, wo das Problem liegt, wenn in dem Verzeichnis 
neben dem Programm noch ein paar Libs liegen.

Stefanus F. schrieb:
> Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht.

Der Betreff beginnt mit dem Namen der Sprache, um die es geht.

Rufus Τ. F. schrieb:
> Stefanus F. schrieb:
>> Ich liebe inzwischen eine Frau.
>
> Damit hast Du diese reichlich überflüssige Diskussion eigentlich sehr,
> sehr schön auf den Punkt gebracht.
>
> Menschen sind viel wichtiger als Programmiersprachen.

Allerdings ist ist der Zweck dieses Forums nicht die Diskussion über 
Menschen.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

findet eigentlich noch jemand das jemand mal den Mod melden sollte?!
Wieso landet so ein Thema bitte in Forum: Offtopic??
Die Kompetenz als Moderator sollte hier doch stark angezweifelt 
werden...

[Karl K. (karl2go)]

Thomas M. schrieb:
> Die Kompetenz als Moderator sollte hier doch stark angezweifelt
> werden...

Lass mich raten: Du bist neu hier im Forum?

[Stefan F. (Gast)]

Thomas M. schrieb:
> findet eigentlich noch jemand das jemand mal den Mod melden sollte?

Was denkst du, wer den Thread dorthin verschoben hat? Die mutmassliche 
Begründung wurde auch schon genannt.

[Mark B. (markbrandis)]

Thomas M. schrieb:
> findet eigentlich noch jemand das jemand mal den Mod melden sollte?!
> Wieso landet so ein Thema bitte in Forum: Offtopic??
> Die Kompetenz als Moderator sollte hier doch stark angezweifelt
> werden...

Das macht man, um einen Thread "elegant" für nicht angemeldete Benutzer 
zu sperren.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

und wenn Kritik am Moderator geübt wird..damit es nicht eskaliert..er 
wird es nie lernen...und da wundert er sich über den Uensurheini

[Stefan F. (Gast)]

Über den Zensurheini wundert sich niemand mehr, ausser er selbst. Dass 
der Mann krank ist und Hilfe benötigt, ist mehr als offensichtlich.

[Le X. (lex_91)]

Och ne, müsst ihr den Programmiersprachen-Kleinkrieg unbedingt am 
Sonntag führen?
Das wär die perfekte Zwischendurchlektüre für die Arbeit gewesen.
Hoffentlich gibts den Thread morgen noch.

[Axel S. (a-za-z0-9)]

Thomas M. schrieb:
> "Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar
> nicht kennst."
> Du meinst wie die C Leute bei Pascal  Delphi Lazarus?
> Die ja nur die Schulversion 1.0 kennen?

PASCAL ist eine reine Lehrsprache, unter diesem Namen gibt es gar keine 
Implementierung für den produktiven Einsatz. Die kanonische PASCAL 
Implementierung für den produktiven Einsatz ist Turbo-Pascal und das war 
ein Rohrkrepierer, weil es einzig auf einer Plattform (x86) und unter 
einem Betriebssystem (Win/DOS) verfügbar war [1]. Delphi ist der 
(glücklose) Nachfolger von Turbo-Pascal. Lazarus ist gar keine 
Programmiersprache, sondern eine IDE rund um Free Pascal. Letzteres ist 
die eine, leider viel zu spät erschienene Implementierung von Pascal, 
die plattformübergreifend verwendbar wäre (wenn man es haben wöllte).

Ich habe im Lauf meiner Programmierer-Karriere auch mal eine Zeit mit 
Turbo-Pascal verbracht und muß sagen, daß es für seine Zeit wirklich 
fortschrittlich war. OK, der Compiler hat schrottigen Code erzeugt. 
Dafür war er rattenschnell. Und die IDE hat gepaßt. Und es gab Libraries 
für alles Wichtige. Und der Turbo-Debugger war richtig(!) Klasse.

Trotzdem hing man an der bek(n)ackten Segmentierung des x86 fest und 
konnte entweder >64KB Code oder Datenstrukturen >64KB haben (aber 
nicht beides). Und auf (damals) fetter Hardware mit 64MB RAM oder mehr 
lief das Dingens gar nicht. Windows übrigens auch nicht. Da war es AIX 
(Rechnerraum II auf dem Campus gesponsort von IBM) oder HP-UX. Und 
später Linux. Und die einzige Programmiersprache, die da out-of-the-box 
lief, und sogar noch überall den gleichen Quellcode akzeptierte, war C. 
Das war ein riesiger FORTSCHRITT gegenüber Turbo-Pascal.

Also erzähl mir nichts davon, wer hier nicht über den Tellerrand 
schauen kann. Oh. Und wenn dir C nicht paßt, dann verwende halt eine der 
Alternativen. Java (stinkt). C# (Monokultur, wie weiland TP). Oder 
meinetwegen Ada, Erlang, Lisp, Rust. Ist ja nicht so, daß es keine 
Auswahl gäbe.

Aber hör auf damit, anderen Leuten die Werkzeuge madig zu machen, deren 
Verwendung du nicht beherrschst.


[1] ja, ok. TP 3.0 hatte ich auch mal eine Weile unter den Fingern. Auf 
einem BC5120 und CP/A. Auch ein dead-end. Immerhin mußte man sich keine 
Gedanken um ein Speichermodell machen, denn der Adreßraum war nur 
64KB. Code und Daten.

[Uhu U. (uhu)]

Axel S. schrieb:
> C# (Monokultur, wie weiland TP)

C# gibts auch unter Linux.

[Percy N. (vox_bovi)]

Uhu U. schrieb:
> Axel S. schrieb:
>> C# (Monokultur, wie weiland TP)
>
> C# gibts auch unter Linux.

Delphi gab es dafür auch, hieß nur anders.

[Karl K. (karl2go)]

Axel S. schrieb:
> Delphi ist der
> (glücklose) Nachfolger von Turbo-Pascal.

Möööp. Delphi ist die Entwicklungsumgebung von Borland für ObjectPascal. 
Emberacado hätte nur gerne, dass die Sprache auch Delphi heisst.

> ... Free Pascal. Letzteres ist
> die eine, leider viel zu spät erschienene Implementierung von Pascal

1994: 2GB Daten verwalten
1998: Win32-Unterstützung
2000: FreeBSD-Unterstützung
2003: Linux-Unterstützung
2004: MacOS-Unterstützung

Ich gebe ja zu, leider ist FreePascal die ganzen Jahre auch an mir 
vorbeigegangen. Aber zu behaupten, es wäre "leider viel zu spät 
erschienen" - nur weil es keine Z4 Implementierung gab...

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

@Autor: Axel S. (a-za-z0-9)
dafür das Pascal eine reine Lehrsprache ist, ist der Altiumdesigner aber 
recht erfolgreich damit geschrieben..und Damals Nero oder der 
Totalcommander etc pp..
Delphi/Pascal gibts natürlich auf unter Linux..sowohl vom Emercadeo als 
auch von Freepascal.
Niemand bestreitet das damals Borland den Übergang zu Windows vermasselt 
hatte..aber das ist schon ewig her, seit dem hat sich viel geändert.

Lol..wer macht den C madig?  Es ist halt ein totaler Krampf..das ist 
Fakt.
Wieso fühlst Du dich deshalb persönlich angegriffen?
Man kann doch sagen das man es auch selber Kacke findet, aber es einige 
Vorteile für dich bietet, die es für dich unverzichtbar machen.
Das gilt aber für sehr viele andere nicht..für die überwiegt einfach der 
Stinkfaktor.
Du magst ja offenbar auch kein Pascal ..so what?! deshalb kann man sich 
dennoch über Unzulänglichkeiten einzelner Sprachen ärgern und wie 
bereits von anderen erwähnt, hat C etliche davon, und ja, sicher wirst 
Du auch in Pascal welche finden, aber halt andere!
Und vieles von dem was Du an Pascal bemängelst gilt heute doch gar nicht 
mehr.
C hatte damals auch noch erheblich mehr Unzulänglichkeiten als heute, 
die auch nach und nach ausgebügelt wurden..wo ist also das 
Problem..beide Sprachen haben sich entwickelt, PAscal deutlich mehr, da 
es aber auch mehr aufzuholen hatte..gilt vieles von den damaligen 
Erfahrungen nicht mehr

[Stefan F. (Gast)]

Axel S. schrieb:
> OK, der Compiler hat schrottigen Code erzeugt. Dafür war er rattenschnell.

Und genau das war bei uns in der Schule damals wichtig, denn die 
Computer dort hatten keine Festplatte. Man musste zuerst DOS booten, 
dann die Diskette A mit Pascal und Diskette B mit den eigenen 
Quelltexten einlegen.

bei dieser HW war wichtig, dass man danach die DOS Diskette nicht mehr 
oft benötigte und dass der Compiler schnell ist, sonst war die 
Doppelstunde vorbei, bevor man etwas zustande brachte. Zu dieser zeit 
hatte auch kaum jemand einen PC zu hause um es dort vorzubereiten bzw. 
nachzuarbeiten.

Will sagen: Für die damalige Zeit war Turbo Pascal die bestmögliche 
Wahl.

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Und genau das war bei uns in der Schule damals wichtig, denn die
> Computer dort hatten keine Festplatte...

Haha, Opa erzählt vom Krieg... Ich kenn das zwar auch noch so vom Amiga, 
aber ich würde das AmigaBasic jetzt nicht zur Grundlage meiner Bewertung 
von Programmiersprachen machen.

Die aktuelle Lazarus+FPC Stable ist 3.3GB groß, inklusive der Sourcen 
und halt Crosscompiler für Linux und Linux Arm, Android.

[Einer K. (Gast)]

Thomas M. schrieb:
> Wieso landet so ein Thema bitte in Forum: Offtopic??

Wegen genau diesem Glaubenskrieg.

So endest es immer...
Fruchtlos.

Küchenpsychologie:

Zwei diametral gegensätzliche Möglichkeiten, es gibt!

Erstens:
Man regt sich über die Unzulänglichkeiten von irgendwas/irgendwem auf, 
was man nutzen muss. Aber da es keine Alternative dazu gibt, 
wird/erscheint man krank.
Siehe C-Hater.

Zweitens:
Man arrangiert sich damit. z.B. in dem man sich das Zeugs schön redet. 
Dieses ermöglicht ein zufriedenes/gesundes Leben, und eine erfolgreiche 
Arbeit damit.


Das ist die Wahl: Krank oder gesund.
Die Entscheidung findet im Kopf statt.
Bei jedem einzelnen.
Und ja, Selbstkonditionierung ist eine menschliche Eigenschaft.


Das alles geht auch ganz ohne Priester.

----------------

Thomas M. schrieb:
> Es ist halt ein totaler Krampf..das ist Fakt.

Kennst du das Lied: https://www.youtube.com/watch?v=X94ZM-paqIc ?
Das zeigt den richtigen Umgang mit Problemen.

Oder auch Hazel Brugger, hat die GEZ mal verwertet:
https://www.youtube.com/watch?v=bCxXLMtklfQ

[Karl K. (karl2go)]

Arduino Fanboy D. schrieb:
> Man arrangiert sich damit. z.B. in dem man sich das Zeugs schön redet.
> Dieses ermöglicht ein zufriedenes/gesundes Leben, und eine erfolgreiche
> Arbeit damit.

Nope. Schönreden ermöglicht gerade kein erfolgreiches Arbeiten, weil man 
auf dem ineffizienten Kram hängenbleibt.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

was hat derf Glaubenskrieg damit zu tun?!
Schau dir dei Diskussion mal an..das Thema wurde sachlich aund 
ausführlich ebsprochen erst als es durch war wurden noch nebenbei 
Gespräche geführt..das hat aber nicht dem dem Rest des Threads zu 
tun..Es ist mir völlig unverständlich wie manche Mods heir agieren 
dürfen

[Einer K. (Gast)]

Karl K. schrieb:
> Nope. Schönreden ermöglicht gerade kein erfolgreiches Arbeiten, weil man
> auf dem ineffizienten Kram hängenbleibt.

Wenn man die freie Auswahl hat...
Aber das ist halt nicht immer gegeben.

Arduino Liebhaber werden sich auf C++ konzentrieren müssen.
Die meisten anderen µC Programmierer werden auf C angewiesen sein.
Die beiden Sprachen bieten eine breite Codebasis für µC.

Assembler mal außen vor. Denn es ist weder portabel, noch frei von 
Fußangeln.
Die anderen Sprachen sind einfach nur Exoten auf µC.


-----

Wenn man keinen Einfluss auf die Umstände hat, kann man nur an der 
eigenen Einstellung arbeiten.

Und genau diese Einstellung entscheidet, ob man dabei gesund bleibt, und 
erfolgreich damit arbeitet.

[Rufus Τ. F. (rufus)]

Thomas M. schrieb:
> Schau dir dei Diskussion mal an..das Thema wurde sachlich aund
> ausführlich ebsprochen

Deine Wahrnehmung ist, gelinde gesagt, getrübt.

[Karl K. (karl2go)]

Arduino Fanboy D. schrieb:
> Arduino Liebhaber werden sich auf C++ konzentrieren müssen.

Im FreePascal Forum sind ne Menge Arduino Liebhaber, die Arduino mit 
Pascal programmieren. Tellerrand.

Arduino Fanboy D. schrieb:
> Die anderen Sprachen sind einfach nur Exoten auf µC.

Ach? Ist das so? Weil Du nur noch Bascom kennst?

Von Ada bis MicroPython gibts da mehr, als Du sinnvoll ausprobieren 
kannst.

[Karl K. (karl2go)]

Thomas M. schrieb:
> Es ist mir völlig unverständlich wie manche Mods heir agieren
> dürfen

Nana, Du bist noch nicht lange hier, oder? Das ist doch harmlos, im 
Raspberry Forum wärst Du schon rausgeflogen, wenn Du was gegen die 
Lieblingsprogrammiersprache des Mods gesagt hättest. BTDT, zweimal.

[Le X. (lex_91)]

Karl K. schrieb:
> Von Ada bis MicroPython gibts da mehr, als Du sinnvoll ausprobieren
> kannst.

... und sind Exoten bzw. werden nur für Nischenanwendungen eingesetzt.
Aber ja, geben tut es sie und funktionieren tun die, in ihrer jeweiligen 
Domäne, wohl auch gut.

[Karl K. (karl2go)]

Le X. schrieb:
> ... und sind Exoten bzw. werden nur für Nischenanwendungen eingesetzt.

Nur weil Dir nicht jeder auf die Nase bindet, dass er nicht C einsetzt?

[Le X. (lex_91)]

Karl K. schrieb:
> Nur weil Dir nicht jeder auf die Nase bindet, dass er nicht C einsetzt?

Ich werd mich an deinen Fanboy-Diskussionen nicht beteiligen.
Ich habe keine emotionale Beziehung zu irgendeiner Programmiersprache, 
ich verdien damit lediglich mein Geld.

Freu dich doch einfach dass du ein Exot bist, sei stolz drauf.
Mainstream bzw. Industriestandard kann jeder ;-)

[Bernd K. (prof7bit)]

Thomas M. schrieb:
> auch sowas verursacht in Pascal einen Fehler
> 2);source.pas(13,9) Warning: range check error while evaluating
> constants

Warnung, nicht Fehler.

> in C kommt raus..
> -5536
> Fehlermeldung von C....KEINE!

Alle gängigen C-Compiler können ebenfalls eine Warnung erzeugen. 
Außerdem hat das Ein- oder Ausschalten der Warnungen nichts mit der 
Sprache an sich zu tun, es ist eine Eigenschaft der jeweiligen Toolchain 
und der Konfiguration des jeweiligen Builds.

Du tust Deiner Sache überhaupt keinen Gefallen (das Gegenteil ist der 
Fall) wenn man den Eindruck gewinnt daß Du auf solche lächerlichen 
Nebelkerzen zurückgreifen mußt um irgendein ein Pro-Argument für Pascal 
(oder Contra-Argument gegen C) vorbringen zu können, der Blödsinn da 
oben ist einfach zu durchschauen und jede Oma kann ihn entkräften und 
ist überhaupt kein Argument für oder gegen irgendwas.

Wenn Du ernstzunehmende Argumente vorbringen willst mußt Du die 
wirklichen Unterschiede der jeweiligen Sprachen und deren Vor- oder 
Nachteile herausarbeiten, dazu muß man aber weitaus tiefer graben (oder 
die einschlägige Literatur zu dem Thema studieren) und das was man dabei 
hervorholt muß man selber verstehen und klar definieren und abgrenzen 
können, nicht mit solchem oberflächlichen Wischiwaschi-Blödsinn 
herumwedeln wie die Default-Warneinstellungen irgendeines konkreten 
Compilers, das sagt absolut nichts über die Eigenschaften der Sprache 
aus.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

sorry..genau DAS ist nicht Wischi Waschi..oder an den HAren herbei 
gezogen!
Eine klare Fehlermeldung zu gar keiner Fehlermeldung IST!! berechtigte 
Kritik

[Bernd K. (prof7bit)]

Thomas M. schrieb:
> Eine klare Fehlermeldung zu gar keiner Fehlermeldung IST!! berechtigte
> Kritik

Beide Compiler erzeugen keinen Fehler sondern sie erzeugen beide 
eine klare Warnung. Was sagt dieser Umstand jetzt nochmal konkret über 
den Unterschied zwischen den beiden Sprachen aus?

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

eben NICHT!!
in C kommt keine Warnung,d a kommt absolut nichts..darum geht es hier 
Seitenweise!!
PACAL gibt aber eine Warnung...Fehlermeldung ist kackegal..es geht 
daraum das Du auf einen Schnitzer hingewisen wirst..wie Du das jetzt 
bezeichnen willst  ist albern darüber zu diskutieren.
C lässt es durchgehen und gibt ein falsches Ergebnis, Pascal warnt vor 
einem zu großen Wert der einen Fehler verursachen wird.
Schau die Quellcode Beispiele hat,..ist alles Seitenlang durchgekaut.
Und wenn Du BEIDE Compiler so einstellt das bei eienr Warnung nicht 
compiliet wird..
Gibt PASCAL auf eine FEHLERMELDUNG und C NICHTS ausser einen BUG!!
So zufrieden?!

[Rolf M. (rmagnus)]

Thomas M. schrieb:
> Lol..wer macht den C madig?  Es ist halt ein totaler Krampf..

Damit beantwortest du deine Frage gleich selbst.

> das ist Fakt.

Nein, es ist deine Meinung. Viele halten ihre eigene Meinung für Fakten, 
weil sie es nicht schaffen, diese beiden Dinge sauber auseinander zu 
halten.
Das ist kritisch, weil diejenigen damit implizit jegliche andere Meinung 
für ungültig erklären.

[Bernd K. (prof7bit)]

Thomas M. schrieb:
> C lässt es durchgehen und gibt ein falsches Ergebnis, Pascal warnt

Weder C noch Pascal tun irgendwas. Sie sind lediglich Sprachen, 
abstrakte Definitionen von Grammatik und Syntax, niedergeschrieben auf 
irgendeinem Papier.

Konkrete Compiler tun etwas und die gängigen Compiler für C die man 
heutzutage benutzt können da genauso eine Warnung anzeigen wie Dein 
Pascal-Compiler. Und bei beiden Compilern kann man die ganzen Warnungen 
auch alle ausschalten und ignorieren. Kein Unterschied.

[Rolf M. (rmagnus)]

Thomas M. schrieb:
> eben NICHT!!
> in C kommt keine Warnung,d a kommt absolut nichts..darum geht es hier
> Seitenweise!!

Du willst es nicht begreifen? Nicht "in C", sondern bei deinem 
Compiler mit deinen Compiler-Einstellungen kommt keine Warnung. C 
verbietet Warnungen nicht!
Bei mir warnt der Compiler da. Willst du jetzt behaupten, es sei deshalb 
kein C-Compiler?

[Einer K. (Gast)]

Karl K. schrieb:
> Ach? Ist das so? Weil Du nur noch Bascom kennst?
>
> Von Ada bis MicroPython gibts da mehr, als Du sinnvoll ausprobieren
> kannst.

Statt Argumente, persönliche Anmache.

Ich sachs ja: So werden Glaubenskriege geführt.
Priestertum...

Le X. schrieb:
> Ich habe keine emotionale Beziehung zu irgendeiner Programmiersprache,
> ich verdien damit lediglich mein Geld.
Das halte ich für eine wesentlich gesündere Einstellung.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

@Rolf M
"Du willst es nicht begreifen?"
Nö, Du willst es nicht akzeptieren..Es waren die Warnmeldungen 
eingeschaltet in C!!
"Bei mir warnt der Compiler da. Willst du jetzt behaupten, es sei 
deshalb
kein C-Compiler?"


HAst Du meine Links/Codebeispiele eigentlich gesehen?!?
In 3 verschiedenen C Compilern passiert absolut nichts!
In d und Pascal schon!

Anstatt nur rumzuposaunen das stimmt nicht,  nenne doch deinen Compiler 
ganz einfach, vielleicht kann das dann jemand bestätigen oder 
verneinen...
Aber in meinem Link kannst Du online 3 C Compiler testen mit einem 
Klick! und alle 3 scheitern.
Wenn Du jetzt einen hast der das macht..toll...dann zeigt das ein mal 
mehr ein Problem von C ..das die Compilerwahl je nach Fehler pures Glück 
ist, ob es der richtige ist...
Unter anderen war der ach so hochgelobte gcc dabei und MS Visual C

Bei Pascal gibt es nur den defacto Standard Delphi/Freepascal. Beide 
melden es.

Du wirst doch zugeben müssen das es schon blöd ist, das es pures Glück 
ist, wo was gemeldet wird und so nicht.
Ansonsten gäbe es ja diese Kritik nicht.
Und wenn das jetzt NACHTRÄGLICH in Deiner Oberfläche implementiert 
ist..schön..aber wir reden hiervon üblichen C Compilern nicht von Guis 
oder extra Tools die sich jemand geschrieben hat um solche Fehler zu 
finden..es geht darum was beim Standard gemeldet wird und was nicht


Noch besser, zeig doch mal Deinen kompletten Code, damit man es mal copy 
PAste testen kann oder Dir sagen kann, was bei Deinem Beispiel falsch 
ist

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

ich habs gerade noch mal so ausprobiert..nun gehts ohne Fehler und ohne 
Fehlermeldung?!
Sowohl im Rextester als auch in Codeblocks?
Was mache ich denn jetzt plötzlich falsch?

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main()
{
    uint16_t i = 30000 * 2;
    printf("%d",i);
    return 0;
}

Ergebnis: 60000

[Rufus Τ. F. (rufus)]

Thomas M. schrieb:
> Was mache ich denn jetzt plötzlich falsch?

Du hast immer noch nicht kapiert, was die Ursache des "Problems" ist.

Der Datentyp "int", der vom Compiler für Berechnungen verwendet wird, 
ist je nach Compiler unterschiedlich groß.

Und wenn Du einen Compiler verwendest, der für 32-Bit-Maschinen gedacht 
ist (wie es ein Compiler für den PC oder auch einen ARM ist), dann ist 
ein "int" ein 32-Bit-Datentyp, und die Berechnung liefert keinen 
Überlauf.

Bei einem Compiler für 16-Bit-Maschinen (oder 8-Bit-Maschinen) aber ist 
"int" ein 16-Bit-Datentyp, und es gibt einen Überlauf.

Das ist elementares C und steht in den ersten Kapiteln jedes 
tauglichen Buches über die Sprache drin, und wird in den ersten Wochen 
der Erstsemestervorlesung gelehrt.

--

Ich fände es schön, wenn Du, bevor Du weiter Dinge kritisierst, die Du 
nicht verstehst, weil Du Dich nicht mit ihnen beschäftigen möchtest, Dir 
vielleicht erst mal das nötige Grundlagenwissen aneignen würdest.

Denn das fehlt Dir. Dafür aber bist Du sehr laut.


Und wenn Du keine Lust hast, Dir Wissen anzueignen, dann halte Dich doch 
bitte einfach aus Diskussionen über das entsprechende Thema herasu. Das 
regt Dich weniger auf, und es stört andere nicht.

Ich beispielsweise habe von Ballett echt gar keine Ahnung, und äußere 
mich dazu nicht. Auch über Fußball wirst Du von mir keine Kommentare 
hören, denn das interessiert mich nicht die Bohne.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

"Rufus Τ. F. (rufus) (Moderator)"
"Du hast immer noch nicht kapiert"
Achte auf Deinen Ton Du Vogel!


es geht nun aber auch unter Rextestert Du....!!
Offensichtlich hast Du es nicht gerafft..entweder vorher oder Du 
erkennst den Fehler im Beispiel jetzt nicht..wie auch immer!

Oder eines meiner Beispiele vorher war falsch, deshalb diskutiert mna, 
was Du offenbar nicht schnallst!

Denn wenn das erste Beispiel von mir schon falsch gewesen wäre, wäre die 
ganze Diskussion für die Katz! Verstehst Du?!


Vielleicht sollte ich Dich mal WIEDER beim Forenbetreiber melden!

[Walter K. (vril1959)]

Thomas M. schrieb:
> Sowohl im Rextester als auch in Codeblocks?


... Rufus hat eigentlich schon alles geschrieben!

Welche Entwicklungsumgebung Du nun für das Erlernen der Basics
nutzt - ist auch vollkommen egal!

Kompiliere und Linke zuerst mal nativ auf Ebene der Kommandozeile - dann 
bekommst Du ein Gefühl dafür, was eigentlich wie passiert - und bringst 
Verständnisprobleme von Datentypen und Castings nicht mit "CodeBlocks" 
in Verbindung.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

viel blabla..aber keine Erklärung dafür was an den vorherigen Beispielen 
anders war, die ja ebenfalls im Rextester getestet wurden!

Wenn nicht alle nur labern würden sondern codebeispiele zegien würden 
udn alle die mal eben im onlinecompiler testen könnten, wäre der ganze C 
vs Pascal Kleinkrieg vielleicht schon längst friedlich beendet.

Aber hier kommt immer nur Gelaber teilweise mit völlig falschen 
Erklärungen weil der Threat schon so lang geworden ist, das viele gar 
nicht mehr die ganzen Vergleiche udn Beispiele kennen

[Rufus Τ. F. (rufus)]

Thomas M. schrieb:
> Achte auf Deinen Ton Du Vogel!
>
> es geht nun aber auch unter Rextestert Du....!!

Diese Kombination liest Du Dir bitte nochmal durch.

Thomas M. schrieb:
> Aber hier kommt immer nur Gelaber

Nein. Ich wiederhole es: Du weigerst Dich, Dich mit dem Gesagten 
auseinanderzusetzen.

Das ist bei Dir schon pathologisch.

[Stefan F. (Gast)]

Thomas M. schrieb:
> Es ist halt ein totaler Krampf
> das ist Fakt.

Ich glaube Dir, dass diese Eigenschaft für Dich sehr ärgerlich ist. Für 
mich ist das lediglich eine Eigenschaft die ich berücksichtigen muss und 
kann.

Ich benutze trotzdem C in meinen Elektronik freiwillig. Ich habe gar 
keine Lust, mich dort mit anderen Programmiersprachen auseinander zu 
setzen, obwohl ich viele andere kennengelernt habe und mir durchaus 
dessen bewusst bin, dass C ein alter hässlicher Opa ist.

Sogar in meinen Hobbyprojekten für Linux/Windows Desktop bevorzuge ich 
C++.

Das liegt nicht daran, dass ich von C am meisten Ahnung hätte. Mein 
beruflich fundiertes KnowHow liegt stattdessen bei Java.

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

2> es geht nun aber auch unter Rextestert Du....!!

Diese Kombination liest Du Dir bitte nochmal durch.2

Ich bin kein Moderator Du Vogel! Meine Aufgabe ist es nicht hier zu 
schlichten und für Ordnung zu sorgen, daher hab ich mich auch nicht 
vorbildlich zu verhalten..mir ist das Forum und dessen Zukunft 
wumpe..aber als Moderator sieht die Sache anders aus..da sollte man 
seine Wortwahl etwas überdenken

[Rufus Τ. F. (rufus)]

Thomas M. schrieb:
> aber als Moderator sieht die Sache anders aus..da sollte man seine
> Wortwahl etwas überdenken

Ich stehe zu meiner Wortwahl. Wenn Du Dich in diesem Forum beteiligen 
willst, solltest Du dringend an Deiner Wortwahl arbeiten, denn so, wie 
Du hier auftrittst, verärgerst Du nicht nur mich (was nur mäßig relevant 
ist), sondern vor allem auch die anderen Forennutzer.

[Chris D. (myfairtux) (Moderator)]

Thomas M. schrieb:
> 2> es geht nun aber auch unter Rextestert Du....!!
>
> Diese Kombination liest Du Dir bitte nochmal durch.2
>
> Ich bin kein Moderator Du Vogel!

Du solltest einfach mal Deine Wortwahl überdenken.

> Meine Aufgabe ist es nicht hier zu
> schlichten und für Ordnung zu sorgen, daher hab ich mich auch nicht
> vorbildlich zu verhalten

Dann liegst Du da schlicht falsch. Auch Du solltest hier einen 
vernünftigen Ton anschlagen.

>..mir ist das Forum und dessen Zukunft
> wumpe..aber als Moderator sieht die Sache anders aus..da sollte man
> seine Wortwahl etwas überdenken

Das sollte man immer tun. Und genau darauf weist Rufus Dich hin.

Wenn Du meinst, dass das für Dich nicht gilt, dann bist Du hier schlicht 
falsch.

--

Zum urspünglichen "Problem", das eigentlich keines ist, wurde schon in 
den ersten paar Beiträgen alles gesagt.

Das eigentliche Problem ist, dass viele C eher nebenbei erlernen: man 
programmiert anfangs eher drauflos, modifiziert hier vorhandenen Code, 
nimmt da ein paar Zeilen mit.

Aber fast niemand setzt sich mal hin und liest ein gutes Buch für 
C-Anfänger.

In 99% der Fälle gelingt es den Leuten dann, leidlich C zu verwenden 
aber in dem einen Prozent der Fälle knallt es eben.

Die interne Behandlung von Integern in C ist aber in der Tat 
Grundlagenwissen, das in jedem Kurs/Buch über C vermittelt wird.

[Karl K. (karl2go)]

Uiuiui, mein Compiler schmeisst gerade einen...

"Fatal error: Thread escalation detected!"

[Frank M. (ukw) (Moderator)]

Thomas M. schrieb:
> Was mache ich denn jetzt plötzlich falsch?

Du compilierst für ein 32-Bit-Target. Da ist 2 x 30000 überhaupt kein 
Problem.

Wenn Du für einen 8-Bit AVR compilierst, dann (und nur dann) ist "int" 
nur 16 Bit breit und die Integer-Promotion schlägt zu.

Hier der Beweis, dass avr-gcc meckert, wenn das Ergbnis nicht in 16 Bit 
reinpasst:

#include <stdint.h>

int
main ()
{
    uint32_t i = 30000 * 2;
}

avr-gcc  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99 -da -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d  -c  ../test.c
../test.c: In function 'main':
../test.c:6:24: warning: integer overflow in expression [-Woverflow]
../test.c:6:14: warning: unused variable 'i' [-Wunused-variable]

Und als allerletztes, warum Du keine Warnung ausgegeben bekommst: Du 
hast in diesem Thread sämtliche Hinweise ignoriert, dass man die 
Warnings für den Compiler auch einschalten muss. Natürlich gilt das nur 
für ein Target, auf dem int nur 16 Bit breit ist. Für 32-Bit-Targets 
wirst Du natürlich keine Warnungen erhalten, da es hier korrekt läuft, 
wie Du ja auch schon selbst festgestellt ist.

Und ja: Auch der Hinweis, dass es für einen Unbedarften gar nicht so 
einfach ist, in der Arduino-Entwicklungsuimgebung die Compiler-Warnungen 
einzuschalten, ist hier schon gefallen. Aber es geht durchaus.

[Chris D. (myfairtux) (Moderator)]

@Karl:

Viel zu spät :-)

Eigentlich hätte er schon viel früher "Warning - 'Pascal' and 'C' used 
in same Thread" werfen müssen.

[Einer K. (Gast)]

Thomas M. schrieb:
> daher hab ich mich auch nicht
> vorbildlich zu verhalten.

Das ist eine Abscheulichkeit.
Widerlich!

[Frank M. (ukw) (Moderator)]

Thomas M. schrieb:
> Ich bin kein Moderator Du Vogel! Meine Aufgabe ist es nicht hier zu
> schlichten und für Ordnung zu sorgen, daher hab ich mich auch nicht
> vorbildlich zu verhalten..mir ist das Forum und dessen Zukunft
> wumpe..aber als Moderator sieht die Sache anders aus..da sollte man
> seine Wortwahl etwas überdenken

Ziemlich einseitige Sicht:

Du äußerst Dich gegenüber Deinen Mitlesern respektlos ("Vogel" und 
ähnliches), erwartest aber vom Gegenüber Höflichkeit. Dein Posting 
lassen wir mal schön stehen, da es genau das richtige Licht auf Dich 
wirft.

[Karl K. (karl2go)]

Chris D. schrieb:
> Eigentlich hätte er schon viel früher "Warning - 'Pascal' and 'C' used
> in same Thread" werfen müssen.

Ups, hatte ich abgeschaltet.

Frank M. schrieb:
> Wenn Du für einen 8-Bit AVR compilierst, dann (und nur dann) ist "int"
> nur 16 Bit breit und die Integer-Promotion schlägt zu.

Zugegeben ist das aber schon ein bescheuertes Verhalten, dass der 
Compiler das so "starrköpfig" auch für Konstanten umsetzt.

Das hat mich am Anfang irritiert, als ich von ASM kommend in C 
eingestiegen bin. Sowas wie

.EQU Cvshdn = 16*1024*33/(330+33)/5 ;Schwelle Versorgung low (V bei 
330k/33k, 10bit, 5Vref)

geht im AVR Assembler problemlos (innerhalb der Rundungsgrenzen), 
während es mit #define im AVR GCC falsche Werte liefert, obwohl der 
eigentliche Wert wieder in 16bit signed passt.

[Frank M. (ukw) (Moderator)]

Karl K. schrieb:
> Zugegeben ist das aber schon ein bescheuertes Verhalten, dass der
> Compiler das so "starrköpfig" auch für Konstanten umsetzt.

Er muss da so starrköpfig sein. Egal, ob der Compiler es zur 
Compilier-Zeit selbst ausrechnen kann oder das Target es at-runtime 
ausrechnen muss: Es muss dasselbe rauskommen!

Sonst kann man sich auf gar nichts mehr verlassen - je nach 
Optimierungsstufe muss man sich sonst jedesmal fragen: "Rechnet das 
jetzt der Compiler oder der AVR?!?"

Ich hatte das Argument bereits hier angeführt:

Beitrag "Re: [C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet"

Es gab nur keine Reaktion darauf. Vielleicht muss ich es auch etwas 
schärfer formulieren:

 Code 1:

    uint32_t i = 30000 * 2;

Code 2:

    int a = 30000;
    int b = 2;
    uint32_t i = a * b;

Code 3:

    int a = rand();     // liefert at runtime 30000
    int b = rand();     // liefert at runtime 2
    uint32_t i = a * b;

Es muss in allen 3 Fällen dasselbe Ergebnis rauskommen. Das kann man nur 
gewährleisten, wenn sich der Compiler "starrköpfig" wie das das Target 
(hier: AVR) selbst verhält.

Von daher ist auch W.S' Forderung, der Compiler solle doch intern mit 
256 Bit rechnen, Unsinn. Denn der Compiler muss genau so rechnen wie das 
Target, sonst kämen - je nach Optimierungsstufe - unterschiedliche 
Ergebnisse raus.

[Karl K. (karl2go)]

Frank M. schrieb:
> Code 1:    uint32_t i = 30000 * 2;
>
> Code 2:    int a = 30000;
>     int b = 2;
>     uint32_t i = a * b;

Nee, das Beispiel ist ja Quatsch. Bei Code 2 gibst Du explizit einen 
Datentyp vor:

> Code 1:    uint32_t i = 30000 * 2;
>
> Code 2:    long a = 30000;
>     long b = 2;
>     uint32_t i = a * b;

Und schon kommen unterschiedliche Ergebnisse auf dem AVR. Und am PC 
hängt es davon ab, ob Windows (int=32, long=32) oder Linux (int=32, 
long=64), sobald die Zahlen größer werden.

Sorry, die Idee dahinter ist schon klar, aber trotzdem klingt das nach 
fauler Ausrede, weil man es halt mal so implementiert hat.

[Frank M. (ukw) (Moderator)]

Karl K. schrieb:
> Bei Code 2 gibst Du explizit einen Datentyp vor:

Ja, natürlich "int", denn 30000 ist ein int und 2 ist ein "int".

> Code 1: uint32_t i = 30000 * 2;
> Code 2: long a = 30000;

Falsche Transferleistung Deinerseits:

Wenn Du Code2 in "long a" abänderst, dann musst Du auch in in Code 1 
"30000L" schreiben. Und schon kommt wieder dasselbe raus.

[(prx) A. K. (prx)]

Karl K. schrieb:
> Zugegeben ist das aber schon ein bescheuertes Verhalten, dass der
> Compiler das so "starrköpfig" auch für Konstanten umsetzt.

Entweder rechnet er überall innerhalb des gegebenen Datentyps.
Oder er rechnet überall entsprechend der Breite des Ergebnisses.
Aber nicht je nach Laune und grad der Erkenntnis mal so mal so.

Es wäre doch etwas peinlich, wenn ein völlig korrekt arbeitender 
Compiler bei voller Kenntnis aller Quellen und entsprechender 
Optimierung zu Konstanten anders rechnet, als wenn man jede Quelle 
einzeln mit ohne oder mit schwacher Optimierung rechnet.

Man kann Rechnungen natürlich auch anders definieren, wenn man eine neue 
Sprache erfindet. Indem das Ergebnis einer Addition ein Bit mehr 
benötigt als der breitere Operand, und das Ergebnis einer Multiplikation 
die doppelte Anzahl. Nur sollte man dann in sämtlichen Berechnungen mit 
kleinerem Speicher als Ergebnis explizite Downcasts mit entsprechend 
definiertem Modulo- oder Sättigungsverhalten einbauen, oder Exceptions 
werfen lassen.

Noch sinnvoller - und weitaus besser prüfbar - wird es, wenn man dann 
sämtliche Variablen mit expliziter Wertebereichsangabe versieht, statt 
mit Datentypen fixer von der Plattform definierter Breite. Ok, das wird 
etwas bremsen, aber wenn schon richtig, dann wirklich richtig.

[Frank M. (ukw) (Moderator)]

A. K. schrieb:
> und das Ergebnis einer Multiplikation die doppelte Anzahl.

Das hiesse dann bei AVR, dass dieser eine 16-Bit-Multiplikation 
grundsätzlich in 32-Bit rechnen müsse.

Da sinkt die Verarbeitungszeit aber dramatisch und jeder würde sich die 
Augen reiben: "Warum ist der denn so arschlangsam?!?". Aus diesem Grund 
ist es auch sinnvoll, dass der Programmierer durch Casts der Operanden 
bestimmt, wie die Target-Plattform (oder auch der Compiler) den Ausdruck 
zu berechnen hat.

[(prx) A. K. (prx)]

Frank M. schrieb:
> Das hiesse dann bei AVR, dass dieser eine 16-Bit-Multiplikation
> grundsätzlich in 32-Bit rechnen müsse.

Er müsste die volle 16x16=>32 Bit Multiplikation rechnen. Also 4 
Teilprodukte statt 3. Oft würde aber der Folgecode das wieder 
reduzieren, so dass der Compiler daraus eine sparsamere Multiplikation 
ableiten kann.

Wie gesagt: Wenn man es bei solchen Überlegungen nur halb richtig macht, 
indem man den faulen Kompromiss einfach nur ein paar Zentimeter 
verschiebt, ändert man nicht wirklich etwas am grundsätzlichen Problem.

Oder man orientiert sich an dem, was gut implementierbar ist, und 
jammert dann darüber, dass man wissen muss, was man tut, ohne es 
explizit im Code zu erblicken.

[Karl K. (karl2go)]

Frank M. schrieb:
> Ja, natürlich "int", denn 30000 ist ein int und 2 ist ein "int".

Nicht natürlich. Dein int passt hier "zufällig" weil Du es so gewählt 
hast zum int, mit dem der Compiler die Konstanten berechnet.

[(prx) A. K. (prx)]

Karl K. schrieb:
> Nicht natürlich. Dein int passt hier "zufällig" weil Du es so gewählt
> hast zum int, mit dem der Compiler die Konstanten berechnet.

30000 ist nicht zufällig "int", sondern immer.

[Frank M. (ukw) (Moderator)]

Karl K. schrieb:
> Nicht natürlich. Dein int passt hier "zufällig" weil Du es so gewählt
> hast zum int, mit dem der Compiler die Konstanten berechnet.

Eine numerische Konstante ist per definitionem ein "int". Wenn Du eine 
long-Kontante haben möchtest, musst Du ein L an die Zahlenkonstante 
anhängen. Das sind Basics!

Du kannst nicht vom Compiler verlangen, dass er Zahlenkonstanten so 
behandelt, wie es Dir gerade in den Kram passt.

[Stefan F. (Gast)]

Frank M. schrieb:
> Er muss da so starrköpfig sein. Egal, ob der Compiler es zur
> Compilier-Zeit selbst ausrechnen kann oder das Target es at-runtime
> ausrechnen muss: Es muss dasselbe rauskommen!
>
> Sonst kann man sich auf gar nichts mehr verlassen - je nach
> Optimierungsstufe muss man sich sonst jedesmal fragen: "Rechnet das
> jetzt der Compiler oder der AVR?!?"

Das ist ein sehr einleuchtendes Argument - finde ich.

[Yalu X. (yalu) (Moderator)]

Man betrachte das folgende C-Beispiel (AVR-GCC)

#include <stdio.h>
#include <inttypes.h>

int16_t  i1, i2;
uint32_t u1, u2;

void init(void) {
  i1 = 20000;
  i2 = 3;
}

int main(void) {
  init();
  u1 = i1 * i2;
  u2 = 20000 * 3;
  printf("%"PRIu32"\n", u1);
  printf("%"PRIu32"\n", u2);
}

und den 1:1 nach Pascal (AVR-FPC) übersetzten Code:

program test;

var i1, i2: int16;
var u1, u2: uint32;

procedure init;
begin
  i1 := 20000;
  i2 := 3;
end;

begin
  init;
  u1 := i1 * i2;
  u2 := 20000 * 3;
  writeln(u1);
  writeln(u2)
end.

Anmerkung: Damit die Ausgabefunktionen printf und writeln auf dem AVR
funktionieren, muss ggf. das I/O-System geeignet initialisiert werden,
was jetzt aber vom eigentlichen Problem zu sehr ablenken würde.

Würden alle vorkommenden Multiplikationen mathematisch korrekt
ausgeführt werden, würden beide Programme

60000
60000

ausgeben.

Tatsächlich gibt aber das C-Programm

4294961760
4294961760

und das Pascal-Programm

4294961760
60000

aus.

In C sind beide Ergebnisse auf Grund des beschränkten int-Wertebereichs
aus mathematischer Sicht falsch, aber sie sind in beiden Fällen gleich
falsch.

In Pascal ist (aus demselben Grund wie in C) das erste Ergebnis
mathematisch falsch, das zweite hingegen (weil in Pascal Konstanten
auf spezielle Weise behandelt werden) korrekt.

Ein Pascal-Fan könnte jetzt argumentieren, dass in C 100% der Ergebnisse
mathematisch falsch sind, während es in Pascal nur 50% sind.

Ein C-Fan hingegen würde argumentieren, dass die Ergebnisse zwar
mathematisch falsch, aber wenigstens konsequent falsch sind, während in
Pascal das Ergebnis der Multiplikation davon abhängt, ob die Operanden
als Konstanten oder Variablen gegeben sind.

Wer von beiden recht hat, darüber darf sich jeder sein eigenes Urteil
bilden.

Meine persönliche Meinung dazu:

Die Regeln für die implizite Typkonvertierung bei Integer-Operationen
sind in beiden Sprachen¹ im Vergleich zu anderen Sprachen relativ
kompliziert und schwer zu merken. In Pascal kommt noch aber eine weitere
Regel für die Sonderbehandlung von Konstanten hinzu, was die Sache noch
komplizierter macht. Diese Zusatzregel mag in gewissen Situationen ihre
Vorteile haben, dennoch bevorzuge ich hier das konsequentere Vorgehen
von C. Es gibt auch Bereiche, wo Pascal seine Vorzüge hat, aber dieser
hier gehört meiner Meinung nach definitiv nicht dazu.

———————————————
¹) So verzichtet bspw. Haskell komplett auf implizite
   Typkonvertierungen, weswegen dafür auch kein Regelwerk
   erforderlich ist.

[Frank M. (ukw) (Moderator)]

Yalu X. schrieb:
> In Pascal kommt noch aber eine weitere
> Regel für die Sonderbehandlung von Konstanten hinzu, was die Sache noch
> komplizierter macht. Diese Zusatzregel mag in gewissen Situationen ihre
> Vorteile haben, dennoch bevorzuge ich hier das konsequentere Vorgehen
> von C. Es gibt auch Bereiche, wo Pascal seine Vorzüge hat, aber dieser
> hier gehört meiner Meinung nach definitiv nicht dazu.

Absolute Zustimmung.

Nur mit einem konsequentem Rechenweg wird ein Ergebnis unabhängig von 
der Optmierungsstufe (Compiler rechnet vs. Target rechnet) 
reproduzierbar. Daher ist die Pascal'sche Sonderbehandlung von 
Konstanten inkonsequent und macht das ganze unnötig komplizierter.

[(prx) A. K. (prx)]

Frank M. schrieb:
> Eine numerische Konstante ist per definitionem ein "int".

Wenn eine dezimale Konstante nicht in den Wertebereich von "int" passt, 
wird sie automatisch erst "long", dann "long long" (wenn vorhanden).

Bei Konstanten auf anderer Basis kommen auch noch vorzeichenlose Typen 
in Frage. Bei 16-Bit "int" ist 32768 also implizit "long", 0x8000 aber 
implizit "unsigned". Erst 0x10000 ist "long".

[Frank M. (ukw) (Moderator)]

A. K. schrieb:
> Wenn eine dezimale Konstante nicht in den Wertebereich von "int" passt,
> wird sie automatisch erst "long", dann "long long" (wenn vorhanden).

Ja, sorry, natürlich. Ich wollte jetzt nicht die ganzen 
Sonderbehandlungen (Zahlen ab 32768 und HEX-Schreibweise) auspacken, die 
dann noch mehr verwirren.

Hier ging es um die magische 30000 des TO, die ist - egal wie man es 
dreht und wendet - so oder so "int".

Von daher ist Deine Formulierung

> 30000 ist nicht zufällig "int", sondern immer.

natürlich präziser.

Jetzt fehlen nur noch Oktal- und Binärschreibweisen. Ab wann werden 
diese zu "long"? Welche sind dabei implizit unsigned? ;-)

[Bernd K. (prof7bit)]

Karl K. schrieb:
> Zugegeben ist das aber schon ein bescheuertes Verhalten, dass der
> Compiler das so "starrköpfig"

Wo kämen wir hin wenn der Compiler sich nicht starrköpfig an seine 
eigenen Regeln halten würde? Künstliche Impertinenz?

[Yalu X. (yalu) (Moderator)]

Frank M. schrieb:
> Nur mit einem konsequentem Rechenweg wird ein Ergebnis unabhängig von
> der Optmierungsstufe (Compiler rechnet vs. Target rechnet)
> reproduzierbar. Daher ist die Pascal'sche Sonderbehandlung von
> Konstanten inkonsequent und macht das ganze unnötig komplizierter.

Konsequent und unabhängig von der Optmierungsstufe ist der Rechenweg
auch in Pascal. Es geht bei der Entscheidung, ob ein Ausdruck
mathematisch korrekt oder modulo 2^n berechnet wird, nicht darum, was
der Compiler zur Compilezeit berechnen kann, sondern was im Sinne der
Sprachdefinition als konstanter Ausdruck definiert ist. Danach sind
konstante Ausdrücke

- Literale
- in /const/-Abschnitten definierte Sysmbole
- Verknüpfungen konstanter Ausdrücke mittels der Standardoperatoren

Nur diese werden mathematisch korrekt berechnet, alles andere unterliegt
den Regeln der implizitem Typkonvertierung und wird – wie auch in C –
modulo 2^n ausgewertet.

In folgendem Beispiel

program test;

var i1, i2: int16;
var u1, u2: uint32;

begin
  i1 := 20000;
  i2 := 3;
  u1 := i1 * i2;
  writeln(u1);
end.

berechnet der Compiler das Produkt zwar zur Compilezeit, trotzdem ist
das Ergebnis nicht 60000, sondern 4294961760, weil im Ausdruck i1*i2 die
Operanden keine Konstanten, sondern Variablen (mit zur Compilezeit
bekanntem Wert) sind.

Insofern ist das Ergebnis auch in Pascal klar definiert. Pascal verfolgt
bei der Auswertung von Ausdrücken nur eine etwas andere Philosophie als
C, die man mögen kann oder auch nicht.

[Frank M. (ukw) (Moderator)]

Yalu X. schrieb:
> Konsequent und unabhängig von der Optmierungsstufe ist der Rechenweg
> auch in Pascal.

Das hatte ich auch schon so verstanden. Mit "inkonsequent" meinte ich 
die "magische" Sonderregel bzgl. der Behandlung von Konstanten. Warum 
muss das sein?

Ein Optimierer könnte bei C so vorgehen:

Schritt 1: Original-Source:

   int a = 30000;
   int b = 2;
   uint32t_ i = a * b;

Schritt 2: Wegoptimieren der Variablen & Zusammenfassen der Konstanten:

   uint32t_ i = 30000 * 2;

Schritt 3: Berechnung des Produktes im int-Zahlenbereich des Targets.

Hier sind die Optimierungsschritte transparent und auch für einen 
unbedarften Leser verständlich. Hier führen die obigen Schreibweisen zu 
demselben Ergebnis.

Ein Pascal-Optimierer darf den Schritt von 1 nach 2 jedoch nicht 
vollziehen, denn beide Schreibweisen führen in Pascal zu 
unterschiedlichen Ergebnissen, wie Du oben auch schön demonstriert hast. 
Hier muss ein Pascal-Optimierer wegen der Sonderbehandlung von 
Konstanten einen Schlenker einbauen.

Dass beide Schreibweisen oben in Pascal nicht äquivalent sind, weiß 
bestimmt auch nicht jeder Pascal-Programmierer. Dies könnte für ihn 
ebenso zur "bösen Falle" werden - um wieder zum Thread-Titel zu kommen 
;-)

[Stefan F. (Gast)]

Yalu X. schrieb:
> Literale...werden mathematisch korrekt berechnet

Sicher hat auch das irgendwo seine Grenzen. Auch Pascal kann nicht 
beliebig grosse Zahlen berechnen.

[(prx) A. K. (prx)]

Und dann hätten wir noch den C Präprozessor, der zwar selten rechnet, 
dann aber nicht unbedingt streng nach den gleichen Regeln wie C.

[Uhu U. (uhu)]

Auf dem 8-Bitter funktioniert diese Variante:

unsigned i = 30000u * 2;

Für unsere C-Basher dürfte das aber zu sperrig sein, als dass es auf 
Dauer in deren Hirn-Biotop überleben könnte…

[Uhu U. (uhu)]

A. K. schrieb:
> Und dann hätten wir noch den C Präprozessor, der zwar selten rechnet,
> dann aber nicht unbedingt streng nach den gleichen Regeln wie C.

Mir ist noch kein derartiger Fall untergekommen - das Ergebnis war stets 
nur ein Ausdruck, den der Compiler dann berechnet hat, sofern das zur 
Compilezeit möglich ist.

Hast du ein Beispiel, wann der cpp rechnet?

[Bernd K. (prof7bit)]

Uhu U. schrieb:
> Hast du ein Beispiel, wann der cpp rechnet?

Beim Auswerten der Bedingung für ein #if kann man ihn zum Rechnen 
zwingen.

[Yalu X. (yalu) (Moderator)]

Stefanus F. schrieb:
> Yalu X. schrieb:
>> Literale...werden mathematisch korrekt berechnet
>
> Sicher hat auch das irgendwo seine Grenzen. Auch Pascal kann nicht
> beliebig grosse Zahlen berechnen.

Sicher. Die Berechnungen scheinen in 64-bit-signed ausgeführt zu werden.
±2**63 ist aber für AVR-Verhältnisse praktisch unendlich ;-)

[Uhu U. (uhu)]

Bernd K. schrieb:
> Beim Auswerten der Bedingung für ein #if kann man ihn zum Rechnen
> zwingen.

OK, da muss er, weil er das #if auswerten muss. Aber im C-Text rechnet 
er, soviel ich weiß, nie.

[Uhu U. (uhu)]

Yalu X. schrieb:
> ±2**63 ist aber für AVR-Verhältnisse praktisch unendlich ;-)

Nein, ist es nicht. Der avr-gcc kennt den Datentyp long long - der ist 
64 Bit lang.

[Karl K. (karl2go)]

Yalu X. schrieb:
> In Pascal ist (aus demselben Grund wie in C) das erste Ergebnis
> mathematisch falsch, das zweite hingegen (weil in Pascal Konstanten
> auf spezielle Weise behandelt werden) korrekt.

Dass der Compiler aber im ersten Fall eine Warnung gibt, ist Dir schon 
aufgefallen?

Womit wir wieder bei "Klar, wenn wir Warnungen ignorieren, können wir 
sonstwas >beweisen<" wären.

[Karl K. (karl2go)]

Uhu U. schrieb:
> Auf dem 8-Bitter funktioniert diese Variante:

Guten Morgen, auch schon aufgewacht.

Nur ist es erstmal unersichtlich, warum eine Zahl 30000 als unsigned 
oder long angegeben werden soll, passt sie doch wunderbar in int.

[Uhu U. (uhu)]

Karl K. schrieb:
> Nur ist es erstmal unersichtlich, warum eine Zahl 30000 als unsigned
> oder long angegeben werden soll, passt sie doch wunderbar in int.

Intelligenz ist, wenn man weiter denkt…

[Karl K. (karl2go)]

Yalu X. schrieb:
> berechnet der Compiler das Produkt zwar zur Compilezeit, trotzdem ist
> das Ergebnis nicht 60000, sondern 4294961760

int01.lpr(17,12) Warning: Range check error while evaluating constants 
(-5536 must be between 0 and 4294967295)

Und wie groß soll der Compiler die Warnung noch schreiben, damit Du 
siehst, dass da was nicht stimmt.

Frank M. schrieb:
> Ein Pascal-Optimierer darf den Schritt von 1 nach 2 jedoch nicht
> vollziehen, denn beide Schreibweisen führen in Pascal zu
> unterschiedlichen Ergebnissen, wie Du oben auch schön demonstriert hast.

Natürlich darf er das und er tut das auch, ist ja nicht blöd. Und dann 
gibts eine Warnung, siehe oben.

[Karl K. (karl2go)]

Uhu U. schrieb:
> Intelligenz ist, wenn man weiter denkt…

Dann mach mal, an einem Beispiel wo es nicht so offensichtlich ist:

.EQU Cvshdn = 16*1024*33/(330+33)/5 ;Schwelle Versorgung low (V bei
330k/33k, 10bit, 5Vref)

Funktioniert so im AVR Assembler. Jetzt bitte in C.

[Stefan F. (Gast)]

Karl K. schrieb:
> .EQU Cvshdn = 16*1024*33/(330+33)/5 ;Schwelle Versorgung low (V bei
> 330k/33k, 10bit, 5Vref)
>
> Funktioniert so im AVR Assembler. Jetzt bitte in C.

Da sehe ich schon auf den ersten Blick, dass 16*1024*33 nicht in einen 
16bit Integer passt.

[Rolf M. (rmagnus)]

Frank M. schrieb:
> A. K. schrieb:
>> und das Ergebnis einer Multiplikation die doppelte Anzahl.
>
> Das hiesse dann bei AVR, dass dieser eine 16-Bit-Multiplikation
> grundsätzlich in 32-Bit rechnen müsse. Da sinkt die Verarbeitungszeit
> aber dramatisch und jeder würde sich die Augen reiben: "Warum ist der
> denn so arschlangsam?!?".

Tatsächlich sind bei den Architekturen, die ich kenne, die 
Multiplikationsergebnisse auf Assembler-Ebene doppelt so groß wie die 
Operanden (auch beim AVR hat mul für jeden Operanden ein Register, 
während das Ergebnis in einem Registerpaar gespeichert wird, siehe 
https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_MUL.html 
). Und dann bekommt man dadurch erst das von dir angesprochene Problem: 
Ich will zwei Werte multiplizieren, das Ergebnis könnte je nach den 
Werten doppelt so groß sein, aber der Compiler verwirft die obere 
Hälfte, da der Ergebnistyp der selbe sein muss wie die Operanden. Ich 
muss also auf Quellcode-Ebene die Operanden erst auf die doppelte Größe 
hochcasten, damit dann die Multiplikation in doppelter Breite 
durchgeführt werden und der Complier dann gefahrlos die obere Hälfte des 
Ergebnisses wegwerfen kann.

Thomas M. schrieb:
> HAst Du meine Links/Codebeispiele eigentlich gesehen?!?
> In 3 verschiedenen C Compilern passiert absolut nichts!

Ich hab mal durchgeschaut. Ich finde keine Links auf deine 3 
verschiedenen C-Compiler, mit denen es nicht funktioniert haben soll. 
Aber vielleicht hab ich es übersehen? Der Thread ist ja schon etwas 
länger.

> Anstatt nur rumzuposaunen das stimmt nicht,  nenne doch deinen Compiler
> ganz einfach, vielleicht kann das dann jemand bestätigen oder
> verneinen...

GCC. Hier ein Link: https://godbolt.org/z/nBWvif

> Aber in meinem Link kannst Du online 3 C Compiler testen mit einem
> Klick! und alle 3 scheitern.

Ich finde nur deinen Pascal-Compiler-Link, wo man auch C-Compiler 
auswählen kann, aber nur für PC, wo sich das Problem nicht ergibt.

> Wenn Du jetzt einen hast der das macht..toll...dann zeigt das ein mal
> mehr ein Problem von C ..das die Compilerwahl je nach Fehler pures Glück
> ist, ob es der richtige ist...

Und das ist in deinem heiß geliebten Pascal anders?

> Unter anderen war der ach so hochgelobte gcc dabei und MS Visual C
>
> Bei Pascal gibt es nur den defacto Standard Delphi/Freepascal. Beide
> melden es.

Aha, also ist Pascal eine bessere Sprache, weil es nur zwei Compiler 
gibt?

[Carl D. (jcw2)]

Karl K. schrieb:
> Uhu U. schrieb:
>> Auf dem 8-Bitter funktioniert diese Variante:
>
> Guten Morgen, auch schon aufgewacht.
>
> Nur ist es erstmal unersichtlich, warum eine Zahl 30000 als unsigned
> oder long angegeben werden soll, passt sie doch wunderbar in int.

Es ist erst mal unersichtlich, warum bei einer Division angegeben werden 
muß, daß gerne eine Interger-Division haben will, obwohl beide Operanden 
und das Ergebnis vom Typ integer sind.

Wenn man will, findet man in jeder Sprache ein Haar. Und obiges ist nur 
eins von vielen. Welche Haarsammlung die beliebtere ist, kann man an 
vielen Kenngrößen ablesen. Wenn man will.

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Da sehe ich schon auf den ersten Blick, dass 16*1024*33 nicht in einen
> 16bit Integer passt.

Hallo? Beispiel für C? Überfordert?

[Stefan F. (Gast)]

Karl K. schrieb:
> Hallo? Beispiel für C? Überfordert?

Die Frage ist mir echt zu kindisch.

#include <stdio.h>
#include <stdint.h>

#define Cvshdn 16UL*1024*33/(330+33)/5

int main()
{
    printf("Cvshdn=%li\n",Cvshdn);
    return 0;
}

Was ist daran jetzt so kompliziert?

[Karl K. (karl2go)]

Stefanus F. schrieb:
> Was ist daran jetzt so kompliziert?

Na nix, aber sieht schon komisch aus.

#define Cvshdn 16*1024UL*33/(330+33)/5

sollte aber auch gehen.

[Stefan F. (Gast)]

Karl K. schrieb:
> Na nix, aber sieht schon komisch aus.

Ich bin ganz sicher nicht in in einer C Blase groß geworden. Aber für 
mich ist vollkommen klar, dass einer der ersten beiden Operanden als UL 
gekennzeichnet werden muss, damit die ganze Chose mit einem Long-Integer 
Algorithmus berechnet wird.

Wenn ich ein Ergebnis als Fließkommazahl erwarte, muss ich das ja auch 
ausdrücklich hinschreiben.

[Yalu X. (yalu) (Moderator)]

Karl K. schrieb:
> Yalu X. schrieb:
>> In Pascal ist (aus demselben Grund wie in C) das erste Ergebnis
>> mathematisch falsch, das zweite hingegen (weil in Pascal Konstanten
>> auf spezielle Weise behandelt werden) korrekt.
>
> Dass der Compiler aber im ersten Fall eine Warnung gibt, ist Dir schon
> aufgefallen?

Nein, ist mir nicht. Der FPC 3.3.1 gibt nur folgende Warnungen aus:

pastest.pas(14,9) Warning: Variable "i1" does not seem to be initialized
pastest.pas(14,14) Warning: Variable "i2" does not seem to be initialized

Der GCC 8.2.0:

ctest.c: In function 'main':
ctest.c:15:14: warning: integer overflow in expression of type 'int' results in '-5536' [-Woverflow]
   u2 = 20000 * 3;

Den Überlauf in Zeile 14 sieht keiner der beiden Compiler, da die
Initialisierung von i1 und i2 in einem Unterprgramm erfolgt. Die gleiche
Warnung erscheint übrigens auch für den Code des TE, und das sogar ohne
explizite -Wxxx-Option.

> Womit wir wieder bei "Klar, wenn wir Warnungen ignorieren, können wir
> sonstwas >beweisen<" wären.

So ist es. Man sollte die Warnungen des C-Compilers durchaus ernst
nehmen, dann vermeidet man viele unliebsame Überraschungen :)


Karl K. schrieb:
> Yalu X. schrieb:
>> berechnet der Compiler das Produkt zwar zur Compilezeit, trotzdem ist
>> das Ergebnis nicht 60000, sondern 4294961760
>
> int01.lpr(17,12) Warning: Range check error while evaluating constants
> (-5536 must be between 0 and 4294967295)
>
> Und wie groß soll der Compiler die Warnung noch schreiben, damit Du
> siehst, dass da was nicht stimmt.

Wieso greifst du mich jetzt an? Hat dich dein Kreuzzug gegen C schon so
verblendet, dass du nicht bemerkt hast, dass ich mit diesem Beispiel
dein geliebtes Pascal gegen ungerechtfertigte Kritik verteidigt habe?

Ich habe Frank oben (irrtümlicherweise) so verstanden, dass das Ergebnis
von Integer-Operationen möglicherweise von der Optimierungsstufe des
Compilers abhängt (d.h. davon, ob er ein Ausdruck zur Compilezeit
berechnet oder nicht). Wenn dem so wäre, wäre das Ergebnis in dem
Beispiel wegen der Compilezeitberechnung des Produkts 60000, während es
in meinem Beispiel weiter oben (wo die Berechnung zur Laufzeit
stattfindet) 4294961760 ist. Damit wäre das Verhalten des Compilers
unvorhersehbar, was ein klares Argument gegen Pascal wäre.

Tatsächlich ist das Ergebnis aber in beiden Fällen 4294961760 und
damit unabhängig von der Optimierungsstufe, wodurch die Ehre von Pascal
bzw. dessen Compiler FPC – zumindest, was diesen Aspekt betrifft –
wiederhergestellt ist.

Und dafür, dass ich dies aufgezeigt habe, bellst du mich nun an :-/

[Frank M. (ukw) (Moderator)]

Yalu X. schrieb:
> Ich habe Frank oben (irrtümlicherweise) so verstanden, dass das Ergebnis
> von Integer-Operationen möglicherweise von der Optimierungsstufe des
> Compilers abhängt (d.h. davon, ob er ein Ausdruck zur Compilezeit
> berechnet oder nicht).

Gut, dass Du das richtigstellst. Selbstverständlich habe ich oben 
gefordert, dass unabhängig von der Optimierungsstufe immer dasselbe 
Ergebnis rauskommen muss. Daraus lässt sich dann folgern, dass der 
C-Compiler gar nicht anders kann, als immer im Wertebereich des 
Target-Systems zu rechnen.

q.e.d

[Uhu U. (uhu)]

Karl K. schrieb:
> .EQU Cvshdn = 16*1024*33/(330+33)/5 ;Schwelle Versorgung low (V bei
> 330k/33k, 10bit, 5Vref)
>
> Funktioniert so im AVR Assembler. Jetzt bitte in C.

Man sieht doch auf den ersten Blick, dass 1024*33 größer als 32767 ist - 
der integer overflow ist also sicher und deswegen sorgt man gleich 
dafür, dass der Ausdruck im long format berechnet wird.

Wenn es nicht so augenscheinlich ist, rechnet man entweder nach oder 
bohrt auf Verdacht auf long auf - kostet ja nichts und gibt sogar eine 
Warnung, falls das Ergebnis für die Zielvariable zu groß ist.

Wie es immer ist: man muss die Regeln kennen und beachten, wenn man 
nicht verunglücken will.

[Karl K. (karl2go)]

Yalu X. schrieb:
> dein geliebtes Pascal

Der zweite Moderator, der hier Programmiersprachen personalisiert?

Yalu X. schrieb:
> Tatsächlich ist das Ergebnis aber in beiden Fällen 4294961760 und
> damit unabhängig von der Optimierungsstufe

Was aber nur daran liegt, dass Du im ersten Beispiel zu einem Trick 
greifst und die Konstantenzuweisung in eine Subroutine auslagerst. 
Machst Du das im Hauptprogramm, erkennt der Compiler, dass es Konstanten 
sind, verrechnet diese miteinander und gibt eine Warnung wegen 
Bereichsüberschreitung.

Es ist völlig egal, wie falsch der Compiler hier rechnet. Er gibt eine 
Warnung aus, und damit ist klar, hier muss was geändert werden. In dem 
Fall ist das ein einfaches und überschaubares Beispiel. Du kannst ja mal 
spasseshalber die Druckberechnung für einen BME280 für AVR optimieren.

Und es ist auch illusorisch zu sagen, durch das Verhalten des 
C-Compilers wird es portierbar. Unter Windows ist int 32 Bit, unter AVR 
16 Bit. Damit funktioniert die Druckberechnung beim Test unter Windows, 
übertragen auf den AVR aber nicht mehr. BTDT.

[Uhu U. (uhu)]

Karl K. schrieb:
> Und es ist auch illusorisch zu sagen, durch das Verhalten des
> C-Compilers wird es portierbar.

Es lässt sich aber leicht machen: man definiert sich abhängig von der 
vordefinierten Kontanten INT_MAX den passenden Datentyp.

INT_MAX ist in limits.h definiert.

[Frank M. (ukw) (Moderator)]

Karl K. schrieb:
> Der zweite Moderator, der hier Programmiersprachen personalisiert?

Lass doch mal den Moderator da raus. Auch wir als Moderatoren möchten 
wie jeder andere auch als normale User am Forum teilnehmen. Wenn wir als 
Moderator fungieren, dann teilen wir das schon mit.

Keinesfalls kannst Du uns eine persönliche Meinung zu einem Thema 
absprechen. Du kannst Dir gewiss sein, dass wir das gut auseinander 
halten können.

[Frank M. (ukw) (Moderator)]

Karl K. schrieb:
> Und es ist auch illusorisch zu sagen, durch das Verhalten des
> C-Compilers wird es portierbar.

Wenn man sich anschaut, auf wie viele unterschiedliche Plattformen Linux 
portiert wurde (mehrer Dutzende), würde ich sagen: Die Tatsachen 
sprechen gegen Dich. Und Linux (von den ganzen anderen Unix-Derivaten 
spreche ich noch nichtmals) ist nicht das einzige Betriebssystem, was in 
C geschrieben wurde. Von wegen Illusion.

Wie viele Betriebssysteme würden dagegen in Pascal geschrieben? Ich 
kenne keins. Ganz entfernt könnte einem noch Oberon in den Kopf 
schiessen. Aber das ist eine ganz andere Liga.

[Uhu U. (uhu)]

Frank M. schrieb:
> Wie viele Betriebssysteme würden dagegen in Pascal geschrieben? Ich
> kenne keins.

Mindestens eins: Solo.

The Solo Operating System: A Concurrent Pascal Program
https://www.researchgate.net/publication/220281517_The_Solo_Operating_System_A_Concurrent_Pascal_Program

[Yalu X. (yalu) (Moderator)]

Karl K. schrieb:
> Yalu X. schrieb:
>> Tatsächlich ist das Ergebnis aber in beiden Fällen 4294961760 und
>> damit unabhängig von der Optimierungsstufe
>
> Was aber nur daran liegt, dass Du im ersten Beispiel zu einem Trick
> greifst und die Konstantenzuweisung in eine Subroutine auslagerst.
> Machst Du das im Hauptprogramm, erkennt der Compiler, dass es Konstanten
> sind, verrechnet diese miteinander und gibt eine Warnung wegen
> Bereichsüberschreitung.

Genau ist es auch in C.

> Und es ist auch illusorisch zu sagen, durch das Verhalten des
> C-Compilers wird es portierbar. Unter Windows ist int 32 Bit, unter AVR
> 16 Bit. Damit funktioniert die Druckberechnung beim Test unter Windows,
> übertragen auf den AVR aber nicht mehr. BTDT.

Die Portierungsprobleme wegen unterschiedlicher nativer Wortbreite gibt
es auch in Pascal.


Leute, die Unterschiede zwischen C und Pascal sind bei Weitem nicht so
groß, wie es von einigen immer wieder behauptet wird. Ganz im Gegenteil:
Die Unterschiede zwischen den beiden Sprachen an sich sind so marginal,
dass es sich kaum lohnt, sich deswegen in die Haare zu geraten.

Dass sich letztendlich C/C++ gegenüber Pascal/Object-Pascal durchgesetzt
hat, liegt auch überhaupt nicht daran, dass es die bessere Sprache wäre,
sondern hängt ganz einfach damit zusammen, dass sich die C-Familie bzgl.
der

- Nutzbarkeit für reale Anwendungen,

- der Einführung neuer Features wie die Objektorientierung,

- der Verfügbarkeit für verschiedene Plattformen (insbesondere
  Mikrocontroller),

- der Optimierungfähigkeiten der Compiler

- u.v.m.

schneller entwickelt hat als die Pascal-Familie.

Zwar war Pascal 1 bis 2 Jahre früher am Start als C, trotzdem hinkte es
in den o.g. Punkten gegenüber von C immer um mindestens 1 bis 2 Jahre
hinterher.

Es gibt auch durchaus Punkte, bei denen Pascal die Nase vorn hat, aber
offensichtlich reicht dieses Delta nicht aus, um C/C++-Programmierer ins
Pascal-Lager zu locken.

[Uhu U. (uhu)]

Yalu X. schrieb:
> Die Portierungsprobleme wegen unterschiedlicher nativer Wortbreite gibt
> es auch in Pascal.

Nicht aus Jux und Dollerei verwendet man nicht die nativen Datentypen, 
sondern definiert sich passende, abhängig von INT_MAX & Co. per typedef…

Das sind dann die allseits bekannten int*_t- und uint*_t-Typen.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

Es ist ja nicht mal die Frage nach der Programmiersprache, welche das 
Problem auslöst.
 Vielmehr ist es das mehr oder weniger vorhandene Verständnis der 
Implementation von allgemeingültigen mathematischsymtaktische Ausdrücken 
in konkrete resuorcenbasierte Beschränkungen realer Binärtechniken.

 Alles steht und fällt mit der unterschiedlich stark beschränkten 
Wortbreite sowie der resultierendn Vermengung von Betrag und Signum.

 Wer das nicht verinnerlicht und die Datentypen nicht auseinanderhalten 
kann, kann weder mit manueller noch mit automatischer Typzuweisung 
umgehen, geschweige denn mit impliziten Typumwandlungen. Das ist völlig 
Sprachunabhängig.

Man muss die Regeln kennen sowohl zu korrekten Anwendung, als auch, um 
sie mit korrektem Ergebnis brechen zu können, wie immer im Leben.

Dass (Ur)Pascal restriktiver damit umging ist für Nichtinformatiker von 
Vorteil. Aber die Entwicklung hin zu mehr Comfort zeitigt dort, wie in 
allen Anderen Programmiersprachen, die gleichen Fussangeln, weil diese, 
wie beschrieben, tiefer liegen und struktureller Natur sind und damit 
unabhängig von der syntaktischen Implementierung.

C bietet in sofern mehr dem Programmierer mehr möglichkeiten in dem es 
weniger restriktiv ist. Der Preis ist die höhere Anforderung an der 
Codeentwickler sich über das zu erwartende Ergebnis seiner 
Problemimplementation im klaren zu sein.

Freiheit versus (Eigen)Verantwortung, wie immer im Leben.
Und Kenntniss der Zusammenhänge gibt Freiheit und erfordert 
Selbtstkontroll. Unkenntniss setzt Grenzen.

Namaste

[A. S. (Gast)]

Uhu U. schrieb:
> Nicht aus Jux und Dollerei verwendet man nicht die nativen Datentypen,
> sondern definiert sich passende, abhängig von INT_MAX & Co. per typedef…

Die einem in der Praxis trotzdem nicht viel weiter helfen.

Integer Promotion und %i kümmern sich wenig um uint16_t. Portabel artet 
das in obfuscating aus, Warnung vor redundanten casts oder 
Bereichsüberschreitungen inklusive.

Und bei der Nutzung verschiedener Compilerwelten sind dann je typedef 
Gräber von #ifdef notwendig, wchar_t macht mich da wahnsinnig.

[Stefan F. (Gast)]

Man könnte sich genau so gut über Taschenrechner beklagen. Die berechnen 
einige Aufgaben auch nicht sauber nach den Regeln der Mathematik.

Zum Beispiel: ist bei diesen Geräten die Wurzel aus 4 = 2.

Dabei könnte es auch -2 sein, was jeder Taschenrechner verheimlicht. 
Rege Dich doch darüber auf, denn das betrifft noch viel mehr Menschen, 
als die Programmiersprachen.

[Robert L. (lrlr)]

Thomas M. schrieb:
> weil das nicht Teil dieser Diskussion ist..es geht um die Falle das
> in C einen Fehler verursacht, was auf den ersten Blick unverständlich
> ist!
> Was in Pascal/Delphi, Freepascal/Lazarus PAscal so funktioniert wie man
> es logisch erwartet gibt in C einen bösen Fehler!
> Das von dir genannte Beispiel ist aber für jeden sofort ersichtlich,d as
> es schlicht grob falsch war..klar wäre es gut wenn auch sowas nicht
> durch den Compiler ginge, aber es ist klar ersichtlich, selbst für nicht
> C Programmierer
>
>

> //fpc 3.0.0
> 
> program HelloWorld;
> Uses sysutils;
> 
> var i : Longint;
>     a : Integer;
>     b : Integer;
> 
> begin
>    a := 30000;
>    b := 2;
>    i := a * b;
> 
>     writeln(inttoStr(i));
> end.
>

>
> zum Onlinecompiler
> https://rextester.com/l/pascal_online_compiler

//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    a : Word;
    b : Word;
    
begin
   a := 30000;
   b := 2;
   i := a * b;

    writeln(inttoStr(i));
end.

meintest du wahrscheinlich

Warum C-hater ganz oben "-30" für den Beitrag erhält, versteh ich 
nicht.. (inhaltlich hat er Recht, ..)

für die "typischen" C stolperfall  wie "if (a=b) {...}"  gibt es 
inzwischen ja auch Warnungen.. es ist "euch" also durchaus bewusst, wo 
die "schwächen" liegen..

[(prx) A. K. (prx)]

Robert L. schrieb:
> Warum C-hater ganz oben "-30" für den Beitrag erhält, versteh ich
> nicht.. (inhaltlich hat er Recht, ..)

Du hältst den Begriff "Dreckssprache" für ein passendes Argument? 
Ausserdem hat er eine einschlägige Vorgeschichte als jemand, der Threads 
in die Gosse zieht.

[Einer K. (Gast)]

Robert L. schrieb:
> Warum C-hater ganz oben "-30" für den Beitrag erhält, versteh ich
> nicht..

Für seine Hasspredigt!
Gerne auch mit täuschen, lügen und Zwietracht sähen.
Üblicher weise, gespickt mit Schimpfworten.

Sobald jemand äußert, mit C oder C++, klar zu kommen rastet er aus.
Wie ein kleines Kind, welches anderen Kindern die Förmchen kaputt tritt. 
Nicht um eines Vorteils willen, sondern aus purem Zerstörungsdrang.


Meine vorläufige Diagnose:
Neurotische Fehlanpassung, mit starken antisozialen Tendenzen.

[Robert L. (lrlr)]

>"Dreckssprache"
nein,
aber wenn man dafür ein "schöneres Wort" ("unintuitiv" oder ähnliches) 
einfügt, und den Rest vom Posting liest, hat er grundsätzlich recht..

ok -30 für Populismus.. , ja kann man durchgehen lassen..

[Purzel H. (hacky)]

> Fast alle Programmiersprachen verhalten sich so.

Nun, man muss eigentlich nur einer Konstanten einen Typ vorschreiben. 
Was man ja kann.

[Einer K. (Gast)]

Name H. schrieb:
> Nun, man muss eigentlich nur einer Konstanten einen Typ vorschreiben.
> Was man ja kann.

Natürlich!

Der Code im Eingangsposting arbeitet mit magischen Zahlen im Code.
Das ist schlechter Stil.
Nebenbei führt das auch zu dem eingangs genannten Überlauf Problemen.



Besser ist sowas:

const uint32_t value  = 30000;
const uint32_t faktor = 2; // hier kann man auch einen kleineren Type wählen



void setup() {
  Serial.begin(9600);

  uint32_t i = 30000 * 2; // Das ergibt keine 60000, sondern 4294934528
  Serial.println(i);

  uint32_t ergebnis = value * faktor; // Das ergibt 60000
  Serial.println(ergebnis);
}

void loop() {
}

Etwas mehr Schreibarbeit, aber in vielerlei Hinsicht sauberer.

Ob man Konstanten und
> uint32_t ergebnis = value * faktor; // Das ergibt 60000
oder
> uint32_t ergebnis = 30000 * 2UL; // Das ergibt 60000
verwendet, hat keine Auswirkung auf das Laufzeitverhalten. Es wird der 
gleiche Code erzeugt



----

Und wie schon von mehreren gesagt:
Wenn man die Warnungen abschaltet, oder abgeschaltet lässt, darf man von 
dem Verhalten überrascht sein.

Aber Warnungen zu ignorieren, gehört meist in den Bereich Dummheit

E:\Programme\arduino\portable\sketchbook\Forum\sketch_mar12a\sketch_mar12a.ino: In function 'void setup()':

E:\Programme\arduino\portable\sketchbook\Forum\sketch_mar12a\sketch_mar12a.ino:10:22: warning: integer overflow in expression [-Woverflow]

   uint32_t i = 30000 * 2; // Das ergibt keine 60000, sondern 4294934528

                ~~~~~~^~~

[Uhu U. (uhu)]

Stefanus F. schrieb:
> Dabei könnte es auch -2 sein, was jeder Taschenrechner verheimlicht.

Er verheimlicht es nicht, er setzt voraus, dass der Nutzer die 
Grundbegriffe kennt ;-)

[Thomas E. (thomase)]

Stefanus F. schrieb:
> Zum Beispiel: ist bei diesen Geräten die Wurzel aus 4 = 2.
>
> Dabei könnte es auch -2 sein, was jeder Taschenrechner verheimlicht.

-2, 2

Das würden viele Experten aber als Minus Zweikommazwei lesen. Deshalb 
lass es lieber wie es ist. Wen es interessiert, der kommt da auch so mit 
klar.

[Christopher C. (trihexagon)]

A. S. schrieb:
> Uhu U. schrieb:
>> Nicht aus Jux und Dollerei verwendet man nicht die nativen Datentypen,
>> sondern definiert sich passende, abhängig von INT_MAX & Co. per typedef…
>
> Die einem in der Praxis trotzdem nicht viel weiter helfen.
>
> Integer Promotion und %i kümmern sich wenig um uint16_t. Portabel artet
> das in obfuscating aus, Warnung vor redundanten casts oder
> Bereichsüberschreitungen inklusive.

Wo ist das Problem?

#include <stdio.h>
#include <inttypes.h>

int main()
{
    uint32_t val = UINT32_C(30000) * 2;
    printf("%"PRId32"\n", val);

    return 0;
}

[Robert L. (lrlr)]

Besser ist sowas:

const uint32_t value  = 30000;
const uint32_t faktor = 2; // hier kann man auch einen kleineren Type 
wählen

warum?
mit welcher Begründung bei 2 ??

bei 30000 könnte man auch "hier kann man auch einen kleineren Type 
wählen" hinschreiben

das Problem ist im Kern das Selbe.. nur um ein paar Zeilen nach oben 
verschoben..

was ist eigentlich der Nachteil, so wie es Pascal macht?

https://rextester.com/LWBNU8599

[Karl K. (karl2go)]

Arduino Fanboy D. schrieb:
> Etwas mehr Schreibarbeit, aber in vielerlei Hinsicht sauberer.

Im Gegenteil: Da wird sich jeder erstmal fragen: Häh? Eine 30000 passt 
in ein int16, warum nimmt er hier ein uint32 und verschwendet Speicher. 
Denn das später mit der 30000 der int16 übeschrietten wird ist an der 
Stelle nicht ersichtlich.

Konsequent fortgeführt, müsste ich alle adc_mean-Variablen mit uint32 
führen, weil irgendwann mal mit einem Faktor verrechnet um von 1024 
Counts auf 5000mV umzurechnen. Da würde ich mir den Code aber schön 
aufblähen.

Sämtliche Divisionen mit shr würden doppelt so lang, obwohl ich den 
adc_mean nur durch 16 teile - was immer noch gut in uint16 passt.

Und der Tiefpassfilter, der mit 15 multipliziert, müsste statt 3x mul - 
was immer noch in uint16 passt, eine 32-Bit Multiplikation in Software 
heranziehen.

Merkst Du, was Du Dir da heranziehst?

Sauber wäre: Die Konstanten und Variablen mit dem Wertebereich zu 
erzeugen, in den sie passen, und dann bei der Berechnung zu casten.

const uint16_t value  = 30000;
const uint8_t faktor = 2;

void setup() {
  Serial.begin(9600);

  uint32_t i = uint32_t(30000) * 2;
  Serial.println(i);

  uint32_t ergebnis = value * faktor; // muss man nicht casten, denn 60000 passt immer noch in uint16
  Serial.println(ergebnis);

  uint32_t ergebnis = uint32(value) * faktor * faktor;
  Serial.println(ergebnis);
}

void loop() {
}

Prinzipiell ist es auf dem AVR sinnvoll, möglicht mit uint zu arbeiten, 
denn mit int werden einige Operationen deutlich aufwendiger, obwohl sie 
das gleiche bewirken.

[Frank M. (ukw) (Moderator)]

Karl K. schrieb:
> Sauber wäre: Die Konstanten und Variablen mit dem Wertebereich zu
> erzeugen, in den sie passen, und dann bei der Berechnung zu casten.

Korrekt. Eine Variable vorsichtshalber (um nicht zu sagen: aus Angst) 
mit dem größten noch einigermaßen praktikablen Datentyp anzulegen ist 
nicht zielführend.

Gerade, wenn ich so einen Angst-Code beispielsweise irgendwo lese, dann 
denke ich sofort: Da hat er etwas Grundlegendes nicht verstanden und hat 
sein Unwissen mit der Keule kaschiert.

> Sämtliche Divisionen mit shr würden doppelt so lang, obwohl ich den
> adc_mean nur durch 16 teile - was immer noch gut in uint16 passt.

Ja, genau in diese Schere würde man laufen.

Man kann Stefan aber noch zugute halten, dass er die beiden Variablen 
wenigstens mit "const" angelegt hat, so dass der Compiler wenigstens 
noch etwas herausholen kann.

[Uhu U. (uhu)]

A. S. schrieb:
> Uhu U. schrieb:
>> Nicht aus Jux und Dollerei verwendet man nicht die nativen Datentypen,
>> sondern definiert sich passende, abhängig von INT_MAX & Co. per typedef…
>
> Die einem in der Praxis trotzdem nicht viel weiter helfen.

Na du scheinst ja ein sehr erfahrener Autor portabler Programme zu sein…

Komisch nur, dass z.B. der Brocken Linux mit all seinen vielen Tools das 
problemlos auf die Reihe bekommt.

Können die Jungs etwa zaubern? Oder pflegen die für jedes Integerformat 
eine eigene Version?

[Einer K. (Gast)]

Karl K. schrieb:
> Im Gegenteil: Da wird sich jeder erstmal fragen: Häh? Eine 30000 passt
> in ein int16, warum nimmt er hier ein uint32 und verschwendet Speicher.
> Denn das später mit der 30000 der int16 übeschrietten wird ist an der
> Stelle nicht ersichtlich.

Das ist eine Konstante und in diesem konkreten Beispiel ist Speicher 
Verbrauch nicht von belang, da es zur Kompilezeit berechnet wird,

Frank M. schrieb:
> Man kann Stefan aber noch zugute halten, dass er die beiden Variablen
> wenigstens mit "const" angelegt hat, so dass der Compiler wenigstens
> noch etwas herausholen kann.

Ich bin nicht Stefan!
Und genau aus dem Grund sind die Dinge Konstant.
Denn: Im Eingangsbeispiel sind sie auch konstant.

Karl K. schrieb:
> Merkst Du, was Du Dir da heranziehst?
Du veränderst die Ausgangslage und machst aus Konstanten Variablen.
Bemerkst Du, deine Verfälschung?

Merke:
Andere Ausgangsbedingung/Aufgabenstellung, andere Lösung.

[Purzel H. (hacky)]

>Stefanus :
>Man könnte sich genau so gut über Taschenrechner beklagen. Die berechnen
einige Aufgaben auch nicht sauber nach den Regeln der Mathematik.
>
>Zum Beispiel: ist bei diesen Geräten die Wurzel aus 4 = 2.
> Dabei könnte es auch -2 sein, was jeder Taschenrechner verheimlicht.

Nein, ist leider nicht richtig.
   wurzel(4) = 2
 aber die Gleichung
   a= wurzel(4)
 hat fuer a zwei Loesungen { +2 & -2 }

Fuer 3.wurzel(x) gibt es drei loesungen, aber nur eine wurzel. Dies, 
weil wurzel(x) eine Funktion ist, bedeutet ein Input, ein Output. Und 
was du meinst ist eine Gleichung.

Ja, ist spitzfindig. Mathematik eben.

[Thomas E. (thomase)]

Robert L. schrieb:
> Warum C-hater ganz oben "-30" für den Beitrag erhält, versteh ich
> nicht.. (inhaltlich hat er Recht, ..)

-25 kriegt er, weil er c-hater ist, nochmal -25 für seine Ausdrucksweise 
und wenn er Recht hat, geht das wieder um 20 nach oben.

[Yalu X. (yalu) (Moderator)]

Uhu U. schrieb:
> A. S. schrieb:
>> Uhu U. schrieb:
>>> Nicht aus Jux und Dollerei verwendet man nicht die nativen Datentypen,
>>> sondern definiert sich passende, abhängig von INT_MAX & Co. per typedef…
>>
>> Die einem in der Praxis trotzdem nicht viel weiter helfen.
>
> Na du scheinst ja ein sehr erfahrener Autor portabler Programme zu sein…
>
> Komisch nur, dass z.B. der Brocken Linux mit all seinen vielen Tools das
> problemlos auf die Reihe bekommt.

Hast du mal darüber nachgedacht, warum Linux nur auf Plattformen läuft,
wofür es

1. einen GCC gibt und

2. int 32 Bit breit ist?

Dafür gibt es natürlich viele Gründe, aber das hier dürfte einer von
ihnen sein.

[Rufus Τ. F. (rufus)]

Yalu X. schrieb:
> warum Linux nur auf Plattformen läuft,
> wofür es
> 1. einen GCC gibt und
>
> 2. int 32 Bit breit ist?

Ist int auf x86_64 unter Linux nicht 64 Bit breit?

[Vn N. (wefwef_s)]

Yalu X. schrieb:
> Hast du mal darüber nachgedacht, warum Linux nur auf Plattformen läuft,
> wofür es
>
> 1. einen GCC gibt und
>
> 2. int 32 Bit breit ist?

Zumindest der Kernel lässt sich AFAIK auch mit LLVM bauen, und fürs 
zweite hätte ich gern eine Quelle. Normal ist eher die MMU das 
limitierende. Mir fällt leider keine halbwegs aktuelle 
16-Bit-Architektur mit MMU ein.

[(prx) A. K. (prx)]

Yalu X. schrieb:
> Hast du mal darüber nachgedacht, warum Linux nur auf Plattformen läuft,
> wofür es
>
> 1. einen GCC gibt und
>
> 2. int 32 Bit breit ist?

Es gab auch Linux für DEC Alpha. Im ILP64 Programmiermodell, also mit 
64-Bit int.

[Frank M. (ukw) (Moderator)]

Rufus Τ. F. schrieb:
>>
>
> Ist int auf x86_64 unter Linux nicht 64 Bit breit?

# cat bit.c && cc bit.c -o bit && ./bit
#include <stdio.h>

int main ()
{
    printf ("int  %d\n", sizeof (int));
    printf ("long %d\n", sizeof (long));
    return 0;
}

int  4
long 8

# uname -a
Linux xxx.de 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u2 (2018-02-21) x86_64 GNU/Linux

[(prx) A. K. (prx)]

Rufus Τ. F. schrieb:
> Ist int auf x86_64 unter Linux nicht 64 Bit breit?

Nein. Das ist LP64, also 32-Bit int und 64-Bit long/pointer. Zu den 
Gründen mag zählen, dass es in ILP64 keine im Standard vorkommenden 
Typen für 16 und 32 Bits gibt. Für eines von beiden müsste ein 
proprietärer Typ her.

Windows ist LLP64, 32-bit int und long, 64 bit long long / pointer.

https://de.wikipedia.org/wiki/64-Bit-Architektur#Programmiermodell

[Yalu X. (yalu) (Moderator)]

vn n. schrieb:
> Yalu X. schrieb:
>> Hast du mal darüber nachgedacht, warum Linux nur auf Plattformen läuft,
>> wofür es
>>
>> 1. einen GCC gibt und
>>
>> 2. int 32 Bit breit ist?
>
> Zumindest der Kernel lässt sich AFAIK auch mit LLVM bauen,

Kann schon sein, zumal Clang sich Mühe gibt, weitgehend GCC-kompatibel
zu sein, um als Ersatz für diesen dienen zu können. Ich glaube aber
nicht, dass sich die Kernel-Entwickler darauf verlassen wollen, dass das
immer so ist, deswegen ist der Standard-Compiler für den Kernel immer
noch GCC.

> und fürs zweite hätte ich gern eine Quelle.

Zwar schon etwas älter, aber daran dürfte sich seither nicht viel
geändert haben:

Obwohl es keine Regel gibt, dass ein int 32 Bits sein muss, ist dies auf
allen aktuell unterstützten Plattformen der Fall.

Aus: Robert Love: Linux-Kernel Handbuch. Leitfaden zu Design und
Implementierung von Kernel 2.6. Übersetzt von Erik Keller.
Addison-Wesley 2005, S. 409.

A. K. schrieb:
> Es gab auch Linux für DEC Alpha. Im ILP64 Programmiermodell, also mit
> 64-Bit int.

Danke, das habe ich nicht gewusst. Ein int größer als die üblichen 32
Bit sollte aber kein Problem darstellen, wenn bei der Programmierung
kein Schindluder getrieben wird wie bspw. die gezielte Nutzung von
Overflows in unsigned int. Mit Problemen wäre vor allem auf Plattformen
mit kleinerem int (bspw. 16 Bit) zu rechnen, da ist mir aber keine
bekannt, auf der Linux (oder auch nur µCLinux) läuft.

[Uhu U. (uhu)]

Yalu X. schrieb:
> Hast du mal darüber nachgedacht, warum Linux nur auf Plattformen läuft,
> wofür es
>
> 1. einen GCC gibt und
>
> 2. int 32 Bit breit ist?
>
> Dafür gibt es natürlich viele Gründe, aber das hier dürfte einer von
> ihnen sein.

Hier kannst du nachlesen, wie der Linux-Quellcode portabel gemacht wird:

   https://lwn.net/images/pdf/LDD3/ch11.pdf

[Walter K. (vril1959)]

Yalu X. schrieb:
> Ich glaube aber
> nicht, dass sich die Kernel-Entwickler darauf verlassen wollen, dass das
> immer so ist, deswegen ist der Standard-Compiler für den Kernel immer
> noch GCC.

Naja .. Linux braucht manchmal halt etwas länger;-)

Aber bei "echten" Unix wie MacOS oder den BSDs siehts anders aus:

Clang / LLVM ist der System-Compiler in FreeBSD 10.0 und höher, und GCC 
wird standardmäßig nicht installiert.

[Bernd K. (prof7bit)]

Uhu U. schrieb:

> [Kernel]
> Können die Jungs etwa zaubern?

Ja ;-)

[Yalu X. (yalu) (Moderator)]

Uhu U. schrieb:
> Hier kannst du nachlesen, wie der Linux-Quellcode portabel gemacht wird:
>
>    https://lwn.net/images/pdf/LDD3/ch11.pdf

Danach ist int auf allen unterstützten Architekturen 32 Bit breit, sogar
auf DEC-Alpha, so dass es bzgl. Integer-Promotion tatsächlich zu keinen
Problemen kommen kann. Und für kritische Variablen kann man ja, wie du
oben schon schriebst, die Typen mit festdefinierter Bitbreite verwenden.

Die Portierung von 32- auf 8-Bit-Prozessoren gestaltet sich aber wegen
der unterschiedlichen int-Größe meist etwas schwieriger. Deswegen gab es
hier im Forum vor kurzem auch eine Anfrage, wie man C-Programme auf dem
PC mit 16-Bit-int kompilieren und ausführen kann, um bspw. komlexere
Rechenalgorithmen auf dem PC vortesten zu können, bevor sie auf den µC
übertragen werden.

Man kann, um die Portabilität zu erhöhen, den Einfluss der Integer-
Promotion auch komplett ausschalten, indem man alle (Teil-)Ausdrücke –
wo erforderlich – geeignet castet. Nur will dann niemand mehr den
verunstalteten Code lesen :)

[Vn N. (wefwef_s)]

Yalu X. schrieb:
> Zwar schon etwas älter, aber daran dürfte sich seither nicht viel
> geändert haben:
> Obwohl es keine Regel gibt, dass ein int 32 Bits sein muss, ist dies auf
> allen aktuell unterstützten Plattformen der Fall.
>
> Aus: Robert Love: Linux-Kernel Handbuch. Leitfaden zu Design und
> Implementierung von Kernel 2.6. Übersetzt von Erik Keller.
> Addison-Wesley 2005, S. 409.

Also ich lese dort nicht raus, dass Linux sich nicht für eine Plattform 
< 32 Bit übersetzen lassen soll, lediglich, dass es aktuell keine solche 
gibt.
Womit wir wieder beim Thema wären, dass Linux eine MMU haben will, und 
mir kein aktueller Prozessor mit 8 oder 16 bit und eingebauter MMU 
einfallen will.

[(prx) A. K. (prx)]

Yalu X. schrieb:
> Danach ist int auf allen unterstützten Architekturen 32 Bit breit, sogar
> auf DEC-Alpha,

Scheint auch logischer, weil man sonst mit einem 16-Bit Typ Probleme 
hat. Die Wikipedia-D erzählt da wohl Mist, die -E enthält das nicht.

[Uhu U. (uhu)]

Yalu X. schrieb:
> Man kann, um die Portabilität zu erhöhen, den Einfluss der Integer-
> Promotion auch komplett ausschalten, indem man alle (Teil-)Ausdrücke –
> wo erforderlich – geeignet castet. Nur will dann niemand mehr den
> verunstalteten Code lesen :)

Wieso alle Teilausdrücke und wieso casten?

Es reicht ein einziges mal der Typ-Postfix an eine Konstante, dann wird 
der gesamte Ausdruck in mindestens dieser Länge berechnet und wenn keine 
Konstante vorkommt, reicht es, eine Variable geeignet zu casten.

[Yalu X. (yalu) (Moderator)]

vn n. schrieb:
> Also ich lese dort nicht raus, dass Linux sich nicht für eine Plattform
> < 32 Bit übersetzen lassen soll, lediglich, dass es aktuell keine solche
> gibt.

Dass es keine gibt, reicht ja schon, um dem Integer-Promotion-Problem
aus dem Weg zu gehen.


Uhu U. schrieb:
> Wieso alle Teilausdrücke und wieso casten?
>
> Es reicht ein einziges mal der Typ-Postfix an eine Konstante, dann wird
> der gesamte Ausdruck in mindestens dieser Länge berechnet und wenn keine
> Konstante vorkommt, reicht es, eine Variable geeignet zu casten.

In

  a * b + c * d

müssen für sizeof(int)=sizeof(x)=2 (x∈{a,b,c,d}) und a*b ≥ 65536 ≤ c*d
mindestens zwei Operanden (bspw. a und c) gecastet werden. Das sieht zum
einen nicht schön aus, zum anderen vergisst man bei komplizierteren
Ausdrücken schnell mal einen Cast.

[Vn N. (wefwef_s)]

Yalu X. schrieb:
> Dass es keine gibt, reicht ja schon, um dem Integer-Promotion-Problem
> aus dem Weg zu gehen.

Du hast aber impliziert, dass es nicht möglich wäre, Linux für 
Plattformen unter 32 Bit zu übersetzen. Und das ist keineswegs bewiesen, 
nur weil es halt keine solche Plattform (mangels Existenz) gibt. 16 Bit 
mit MMU fallen mir nur pProzessoren ein, die lange vor Linux aktuell 
waren...

[Uhu U. (uhu)]

Yalu X. schrieb:
> In
>
>   a * b + c * d
>
> müssen für sizeof(int)=sizeof(x)=2 (x∈{a,b,c,d}) und a*b ≥ 65536 ≤ c*d

Kannst du die Regeln zitieren, aus denen das folgt?

[Vn N. (wefwef_s)]

A. S. schrieb im Beitrag #5768684:
> natürlich weiss ich, dass es auf 16-Bit-Maschinen TRUE und auf
> 32-Bit-Maschinen /(meist)/ FALSE ist

Bitte wo soll das der Fall sein, und warum?

A. S. schrieb im Beitrag #5768684:
> aber bin ich mir dessen immer
> bewusst? [...] Nein.

Tja, jede Programmiersprache hat halt so ihre Regeln, die man kennen und 
beachten sollte, egal ob es nun C ist oder Brainfuck. Ist halt so. Wenn 
dir C nicht gefällt, wechsle halt.

[Yalu X. (yalu) (Moderator)]

vn n. schrieb:
> Yalu X. schrieb:
>> Dass es keine gibt, reicht ja schon, um dem Integer-Promotion-Problem
>> aus dem Weg zu gehen.
>
> Du hast aber impliziert, dass es nicht möglich wäre, Linux für
> Plattformen unter 32 Bit zu übersetzen. Und das ist keineswegs bewiesen

Nein, bewiesen ist das nicht, aber ich halte es angesichts der riesigen
Codebasis für sehr, sehr wahrscheinlich, dass es da zu Problemen kommt.

Aber selbst wenn der Kernel ohne Änderung auch für 16-Bit-Systeme
lauffähig wäre, wäre das eher Glückssache und deswegen schlecht als
Begründung dafür geeignet, dass die Integer-Promotion bei der Portierung
von einem 32- auf ein 16- oder 8-Bit-Plattform niemals Probleme macht.
Uhus Aussage von oben impliziert aber genau dies.


Uhu U. schrieb:
> Yalu X. schrieb:
>> In
>>
>>   a * b + c * d
>>
>> müssen für sizeof(int)=sizeof(x)=2 (x∈{a,b,c,d}) und a*b ≥ 65536 ≤ c*d
>
> Kannst du die Regeln zitieren, aus denen das folgt?

Das kann man ganz einfach an einem Beispiel erklären (int sei 16 Bit
breit):

#include <stdio.h>
#include <inttypes.h>

int main(void) {
  uint16_t a = 1000, b = 1000, c = 1000, d = 1000;
  uint32_t e1 = a * b + c * d;
  uint32_t e2 = (uint32_t)a * b + c * d;
  uint32_t e3 = (uint32_t)a * b + (uint32_t)c * d;
  printf("e1=%"PRIu32" e2=%"PRIu32" e3=%"PRIu32"\n", e1, e2, e3);
}

Ausgabe:

e1=33920 e2=1016960 e3=2000000

Im ersten Fall überlaufen beide Teilprodukte, im zweiten nur eins und im
dritten überhaupt keins. Deswegen braucht man bspw. auf einem AVR beide
Casts, auf einem PC mit 32-Bit-int kann man sich beide sparen.

[Karl K. (karl2go)]

Arduino Fanboy D. schrieb:
> Du veränderst die Ausgangslage und machst aus Konstanten Variablen.

Ja, das war die Vorgabe: Der Compiler muss sich bei 30000 * 2 
verrechnen, egal ob es eine Konstante oder eine Variable ist. Damit das 
immer gleich falsch ist. Wurde mir oben so erklärt.

Also bitte, wenn schon - denn schon, nicht mal so mal so, wie es euch 
gerade in den Kram passt.

[Karl K. (karl2go)]

Uhu U. schrieb:
> A. S. schrieb:
>> Uhu U. schrieb:
>>> Nicht aus Jux und Dollerei verwendet man nicht die nativen Datentypen,
>> Die einem in der Praxis trotzdem nicht viel weiter helfen.
> Na du scheinst ja ein sehr erfahrener Autor portabler Programme zu sein…

Na Du scheinst ja nicht viel Erfahrung zu haben.

Die Druckberechnung für den BMP180 - genauso bescheiden wie für den 
BME280 - am PC zusammengebaut und mit vom AVR ausgelesenen Rohwerten am 
PC getestet. Funktioniert.

Die Routine auf den AVR übernommen: Funktioniert nicht.

Am PC hat der Compiler auch für als uint16, int16 definierte Variablen 
32 Bit verwendet bzw. Multiplikationen auch in 32 Bit ausgeführt und die 
Berechnungen liefen ohne Überlauf durch.

Am AVR hat der Compiler dann die angegeben 16 Bit verwendet bzw. 
Multiplikationen auch nur mit 16 Bit ausgeführt, und das ging halt 
schief.

War ein Test, aber: Nein, man kann nicht davon ausgehen, dass man mit 
uint16... sicher plattformübergreifend ist.

[Rolf M. (rmagnus)]

Yalu X. schrieb:
> Hast du mal darüber nachgedacht, warum Linux nur auf Plattformen läuft,
> wofür es
>
> 1. einen GCC gibt und

Hauptsächlich weil Linus Torvalds nix von Standard-C hält und massiv 
GCC-Erweiterungen nutzt. Das macht es anderen Compilern extrem schwer, 
den Kernel zu übersetzen. Intel hat mal sehr viel Arbeit reingesteckt, 
deren Compiler so weit zu bringen, dass der Kernel damit auch 
übersetztbar war.

> 2. int 32 Bit breit ist?

Linux setzt die POSIX-Spezifikation um, die für int eine Mindestgröße 
von 32 Bit fordert.

A. K. schrieb:
> Rufus Τ. F. schrieb:
>> Ist int auf x86_64 unter Linux nicht 64 Bit breit?
>
> Nein. Das ist LP64, also 32-Bit int und 64-Bit long/pointer. Zu den
> Gründen mag zählen, dass es in ILP64 keine im Standard vorkommenden
> Typen für 16 und 32 Bits gibt. Für eines von beiden müsste ein
> proprietärer Typ her.

Ich denke, das wird der Hauptgrund sein. Eigentlich sollte int der 
native Typ der Zielplattform sein (das ist in ISO C nicht gefordert, 
aber dass es so gedacht ist, wird dort durchaus erwähnt). Bei 
64-Bit-Plattformen würden einem aber die kleineren Typen ausgehen, also 
belässt man es in der Regel bei 32 Bit.

Uhu U. schrieb:
> Yalu X. schrieb:
>> Man kann, um die Portabilität zu erhöhen, den Einfluss der Integer-
>> Promotion auch komplett ausschalten, indem man alle (Teil-)Ausdrücke –
>> wo erforderlich – geeignet castet. Nur will dann niemand mehr den
>> verunstalteten Code lesen :)
>
> Wieso alle Teilausdrücke und wieso casten?
>
> Es reicht ein einziges mal der Typ-Postfix an eine Konstante, dann wird
> der gesamte Ausdruck in mindestens dieser Länge berechnet und wenn keine
> Konstante vorkommt, reicht es, eine Variable geeignet zu casten.

Da hast du glaub ich falsch rum gedacht. Es ging meinem Verständnis nach 
darum, auf dem PC einen Algorithmus für den AVR zu testen und dabei 
nicht in die Falle zu tappen, dass Dinge aufgrund der 32-Bit-Integer auf 
dem PC funktionieren, die auf dem AVR ggf. fehlschlagen würden.

vn n. schrieb:
> Du hast aber impliziert, dass es nicht möglich wäre, Linux für
> Plattformen unter 32 Bit zu übersetzen. Und das ist keineswegs bewiesen,
> nur weil es halt keine solche Plattform (mangels Existenz) gibt.

Dass das out of the box geht, halte ich auch für sehr unwahrscheinlich.

> 16 Bit mit MMU fallen mir nur pProzessoren ein, die lange vor Linux
> aktuell waren...

Wobei eine MMU nicht zwingend nötig ist.
https://de.wikipedia.org/wiki/%CE%9CClinux

Karl K. schrieb:
> Am PC hat der Compiler auch für als uint16, int16 definierte Variablen
> 32 Bit verwendet

Ein uint16_t ist 16 Bit breit. Immer.

> bzw. Multiplikationen auch in 32 Bit ausgeführt

Das schon eher, da - wie schon erwähnt wurde - alle Berechnungen 
mindestens in int ausgeführt werden, also auf dem PC in 32 Bit.

[Uhu U. (uhu)]

Karl K. schrieb:
> Am PC hat der Compiler auch für als uint16, int16 definierte Variablen
> 32 Bit verwendet bzw. Multiplikationen auch in 32 Bit ausgeführt und die
> Berechnungen liefen ohne Überlauf durch.

Weißt du nicht, dass c kleinere Integertypen, als int, bei der 
Parameterübergabe immer auf int erweitert?

Parameter sind bei call by value immer mindestens sizeof int lang.

[(prx) A. K. (prx)]

Uhu U. schrieb:
> Weißt du nicht, dass c kleinere Integertypen, als int, bei der
> Parameterübergabe immer auf int erweitert?

Mit Prototypes werden die Parameter in der Funktion so verwendet, wie 
sie im Prototype deklariert sind. Die genaue Technik der Übergabe ist 
zwar Sache des ABI und kann eine Übergabe als "int" zur Folge haben, 
aber ein Parameter von Typ char wird in der Funktion unabhängig davon 
als char verwendet, mit sizeof(param)==1.

Implizite "int" Konvertierung gibt es nur bei unvollständigen 
Prototypes, also in Funktionen mit variabler Anzahl Parameter wie 
printf, sowie bei fehlenden Prototypes im alten K&R Stil.

[Karl K. (karl2go)]

Uhu U. schrieb:
> Weißt du nicht, dass c kleinere Integertypen, als int, bei der
> Parameterübergabe immer auf int erweitert?

Mööp: Nein, nicht auf dem AVR.

[Axel S. (a-za-z0-9)]

Uhu U. schrieb:
> Weißt du nicht, dass c kleinere Integertypen, als int, bei der
> Parameterübergabe immer auf int erweitert?

Hoffentlich "weiß" das niemand. Das wäre nämlich dann falsch.

Was du vermutlich meinst: in Abwesenheit eines Prototyps (vulgo: 
Deklaration) nimmt C für alle Parameter einer Funktion ebenso wie für 
den Rückgabewert int an. Ganz andere Baustelle.

[Jobst Q. (joquis)]

Winfried J. schrieb:
> C bietet in sofern mehr dem Programmierer mehr möglichkeiten in dem es
> weniger restriktiv ist. Der Preis ist die höhere Anforderung an der
> Codeentwickler sich über das zu erwartende Ergebnis seiner
> Problemimplementation im klaren zu sein.
>
> Freiheit versus (Eigen)Verantwortung, wie immer im Leben.

Wieso "versus" ? Eigenverantwortung lernt man nur in Freiheit. Wenn man 
die Konsequenzen eigener Entscheidungen zu spüren bekommt. Und garnicht 
erst auf die Idee kommt, die Schuld bei anderen zu suchen, von denen man 
ungenügend betreut und kontrolliert wurde.

[Dirk B. (dirkb2)]

Uhu U. schrieb:
> Weißt du nicht, dass c kleinere Integertypen, als int, bei der
> Parameterübergabe immer auf int erweitert?

Das gilt für Funktionen mit variabler Parameterliste wie z.B. printf und 
scanf.
Dort wird statt float auch double benutzt.
Deswegen ist auch kein %lf bei printf nötig.

Bei scanf werden aber meist Adressen übergeben. Da ist ein %lf nötig.