Warnungen beim Compilieren aktivieren

Gast #2451528
Lesenswert?

Peter II schrieb:
> dann schreibe doch mal...

passiert nichts, deswegen habe ich ja gefragt.
1
  if 
2
    (
3
      (
4
        (!(PINB &(1<<T_RELEASE))) && (debounce_t_release == AUS)
5
      )
6
     ||
7
      (
8
        (status ==STATE_SHORTCIRQUIT) && (restart_interlock_timer==0)
9
      )
10
    )

wenn ich nun debounce_t_release == AUS gegen
             debounce_t_release = AUS ersetze merkt er es nicht.
1
if( 5 = xy )...
das hingegen merkt er. Was mache ich denn falsch?
-Wall ist eingeschaltet.

Knut
#2451533
Lesenswert?

Knut schrieb:
> Peter II schrieb:
>> dann schreibe doch mal...
>
> passiert nichts, deswegen habe ich ja gefragt.
>
1
>   if
2
>     (
3
>       (
4
>         (!(PINB &(1<<T_RELEASE))) && (debounce_t_release == AUS)
5
>       )
6
>      ||
7
>       (
8
>         (status ==STATE_SHORTCIRQUIT) && (restart_interlock_timer==0)
9
>       )
10
>     )
11
>
>
> wenn ich nun debounce_t_release == AUS gegen
>              debounce_t_release = AUS ersetze merkt er es nicht.
>
>
1
> if( 5 = xy )...
2
>
> das hingegen merkt er. Was mache ich denn falsch?

Die Reihenfolge!

if ( x = 5 )

ist etwas anderes als

if ( 5 = x )


das erste ist der Versuch an x den Wert 5 zuzuweisen. Das zweite der 
Versuch an 5 den Wert von x zuzuweisen. An 5 kann man nichts zuweisen. 
In C-Speak ist 5 kein L-Value. Das ist ein Syntax Fehler, den dir der 
COmpiler auf keinen Fall duchgehen lassen wird.

Aber ganz ehrlich: derartige Fehler macht man am Anfang ein paar mal, 
dann hat man sich daran gewöhnt einen Vergleich mit == zu schreiben und 
dann kommt es nur noch gaaaanz selten vor.
Gast #2451542
Lesenswert?

Karl Heinz Buchegger schrieb:
> Aber ganz ehrlich: derartige Fehler macht man am Anfang ein paar mal,
> dann hat man sich daran gewöhnt einen Vergleich mit == zu schreiben und
> dann kommt es nur noch gaaaanz selten vor.

Aber wenn von den zwei Tastenanschlägen nur einer ankommt is auch doof.

Aber:
>> wenn ich nun debounce_t_release == AUS gegen
>>              debounce_t_release = AUS ersetze merkt er es nicht.

wo ist hier das Problem, oder stehe ich aufm Schlauch?


Knut
#2451567
Lesenswert?

Knut schrieb:
> Aber:
>>> wenn ich nun debounce_t_release == AUS gegen
>>>              debounce_t_release = AUS ersetze merkt er es nicht.
>
> wo ist hier das Problem, oder stehe ich aufm Schlauch?

Das steht in einer Klammer innerhalb der "if-Klammer". Da bekommst du 
nie eine Warnung, ...
> In der Version davor hat er das immer gemacht, nun nicht mehr.
... auch nicht in der Version davor.

Wenn man ganz bewusst dort eine Zuweisung haben will, schreibt man 
deswegen auch
1
if ( (x = 5) )
#2451578
Lesenswert?

Knut schrieb:

> wo ist hier das Problem, oder stehe ich aufm Schlauch?

Das Problem ist, dass

  if( x = irgendwas )
durchaus legales gültiges C ist, welches auch seinen Sinn haben kann.

Also hat man sich beim GCC auf einen Kompromiss geeinigt:
Schreibt man das so

  if( x = irgendwas )

dann warnt der COmpiler vor der Zuweisung.
Schreibt man das so

  if( (x = irgendwas) )

dann deutet man dem Compiler damit an: Es ist ok, ich will wirklich eine 
Zuweisung haben.

Und du hast eine ( ) rund um deinen Ausdruck: daher -> keine Warnung.
Gast #2451579
Lesenswert?

Stefan Ernst schrieb:
> Das steht in einer Klammer innerhalb der "if-Klammer". Da bekommst du
> nie eine Warnung, ...
>> In der Version davor hat er das immer gemacht, nun nicht mehr.
> ... auch nicht in der Version davor.

Exakt.

  if (x = 9)

generiert eine "suggest parenthesis around assignment used as truth 
value" Warning, aber

  if ((x = 9))

eben nicht.

Der passende Parameter ist -Wparentheses (is bei -Wall schon dabei).

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren