Fallstricke bei der C-Programmierung - Versionsgeschichte

Besserwessi: /* Fehlende Klammer in #define */

2010-06-07T20:26:48Z

‎Fehlende Klammer in #define

2010-06-07T20:20:31Z

‎Zuweisung statt Vergleich: - Tipfehler

2010-06-07T20:02:03Z

‎Zuweisung statt Vergleich: typo und Hinweis auf Warnung

2009-10-26T00:13:53Z

2009-10-26T00:01:46Z

‎Ein , anstatt . in Konstante

2009-10-25T23:59:47Z

‎TRUE ist nicht 1

2009-10-25T23:56:04Z

‎Warnung ignoriert

2008-08-26T19:38:10Z

‎Führende 0 in Konstanten

2008-08-26T19:25:03Z

‎Weitere Fallstricke

2007-06-12T15:01:45Z

‎Zuweisung statt Vergleich: Beschreibung mehr am Beispiel orientiert

@@ Zeile 142: / Zeile 142: @@
 == Fehlende Klammer in #define ==
-Definitionen per #define werden nicht wie mathermatische Funktionen behandelt, sondern es wird einfach der Text eingesetzt.
+Definitionen per #define werden nicht wie mathematische Funktionen behandelt, sondern es wird einfach der Text eingesetzt.
   #define Konstante  (1<<5)+(1<<7)
 ist also riskant, denn 2*Konstante wird durch 2*(1<<5)+(1<<7) ersetzt, was vermutlich nicht beabsichtigt ist. Richtig müsste man

@@ Zeile 17: / Zeile 17: @@
      /* mach was */
+  }
-In einer if-Bedingung wurde beim Vergleich ein <tt>=</tt> vergessen, so dass der Vergleich zu einer Zuweisung wird: Zunächt wird <tt>a</tt> mit dem Wert <tt>0</tt> belegt, und das ist auch der Wert des C-Azsdrucks <tt>a = 0</tt>. Diese if-Bedingung ist also immer falsch und der zugehörende Block wird nie betreten. Zudem wird der Wert von <tt>a</tt> verändert, was bei einem Vergleichnicht der Fall wäre.
+In einer if-Bedingung wurde beim Vergleich ein <tt>=</tt> vergessen, so dass der Vergleich zu einer Zuweisung wird: Zunächt wird <tt>a</tt> mit dem Wert <tt>0</tt> belegt, und das ist auch der Wert des C-Ausdrucks <tt>a = 0</tt>. Diese if-Bedingung ist also immer falsch und der zugehörende Block wird nie betreten. Zudem wird der Wert von <tt>a</tt> verändert, was bei einem Vergleich nicht der Fall wäre.
 Abhilfe schafft, indem man sich angewöhnt zu schreiben
@@ Zeile 23: / Zeile 23: @@
 Wenn man dann eine Zuweisung eintippt, gibt's einen Compiler-Fehler.
 Zudem sollte man immer Compiler-Warnungen aktivieren, so dass bei dem problematischen Code eine Warnung ausgegeben wird. Soll tatsächlich eine Zuweisung ''und'' ein Vergleich geschehen, so kann die Warnung bei gcc mit einer Doppelklammer unterdrückt werden:
-  // Weise a an b zu un teste den Wert auf != 0
+  // Weise a an b zu und teste den Wert auf != 0
   if ((b = a))
+  {

@@ Zeile 17: / Zeile 17: @@
      /* mach was */
+  }
-Bei einer if-Bedingung wird ob der Ausdruck innerhalb der Klammern ungleich <tt>0</tt> (<tt>true</true>) ist, dann wird die darauf folgende Anweisung bzw. Block ausgeführt.  In diesem Codebeispiel ist der Ausdruck eine Zuweisung.  Eine Zuweisung hat den Wert der zugewiesen wird, also hier <tt>0</tt>.  Damit wird bei diesem Code der Block zu der Bedingung nie ausgeführt.
+In einer if-Bedingung wurde beim Vergleich ein <tt>=</tt> vergessen, so dass der Vergleich zu einer Zuweisung wird: Zunächt wird <tt>a</tt> mit dem Wert <tt>0</tt> belegt, und das ist auch der Wert des C-Azsdrucks <tt>a = 0</tt>. Diese if-Bedingung ist also immer falsch und der zugehörende Block wird nie betreten. Zudem wird der Wert von <tt>a</tt> verändert, was bei einem Vergleichnicht der Fall wäre.
 Abhilfe schafft, indem man sich angewöhnt zu schreiben
   if (0 == a)
 Wenn man dann eine Zuweisung eintippt, gibt's einen Compiler-Fehler.
 ==Signal/Interrupt-Name vertippt (avr-gcc)==

@@ Zeile 203: / Zeile 203: @@
      ...
 Oder je nach Programmstruktur sichert man den Wert, z.B. in eine lokale Variable oder deaktiviert nur selektiv die kritischen Interrupts, also solche, die Einfluss auf die kritischen Daten nehmen.
 = Weitere Fallstricke =

@@ Zeile 124: / Zeile 124: @@
 Die <tt>14;</tt> ist ein Ausdruck, der nicht weiter gebraucht wird und daher wegfällt, da
 er im Gegensatz zu einer void-Funktion keine Wirkung hat.
-Man rechnet also mit dem Wert&nbsp;3 für <math>\pi</math>.
+Man rechnet also mit dem Wert&nbsp;3 für <math>\pi</math>, aber auch dieses Problem würdigt gcc mit einer Warnung.
 Das falsche Komma hat auch schon so manchen ebay-Freak aufs Kreuz gelegt...

← Nächstältere Version		Version vom 25. Oktober 2009, 23:59 Uhr
Zeile 108:		Zeile 108:

	Siehe auch: http://www.dclc-faq.de/kap8.htm#8.2		Siehe auch: http://www.dclc-faq.de/kap8.htm#8.2
		+
		+	Auf der anderen Seite wird oft auch schon "TRUE" in einem der Standart-include-files definiert und sollte dann nicht mehr neu definiert werden.

	==Ein , anstatt . in Konstante==		==Ein , anstatt . in Konstante==

@@ Zeile 57: / Zeile 57: @@
 prog.c:5: warning: passing arg 1 of `foo' from incompatible pointer type
 </pre>
 ==Array-Index==

@@ Zeile 129: / Zeile 129: @@
 daß die Zahl oktal dargestellt ist. Somit ist 010 nicht gleich 10.
   if (a == 030) // ist a gleich 24?
 =Nicht-atomarer Code=

← Nächstältere Version		Version vom 26. August 2008, 19:25 Uhr
Zeile 193:		Zeile 193:

	= Weitere Fallstricke =		= Weitere Fallstricke =
		+	== Überlauf bei Konstanten ==
		+	Ohne extra Angaben werden Konstanten als Integer berechnet.
		+	Zum Beispiel wird (2<<15) als 0 behandelt, da die unteren 16 Bits Null sind. Leider geben einige Compiler hierbei nicht einmal eine Warnung aus.
		+	Um das erwartete Ergebniss zu erhalten muss man (2L<<15) schreiben. Dann wird eine Long Datentyp verwendet.
	* [[Warteschleife]]		* [[Warteschleife]]