Warnung bei if (variable) bla();

Ingo schrieb:
> Nur kommt halt keine Warnung.

Du bräuchtest sowas wie -WcurrentlyUsingC : „warning: using C language 
is highly risky if not done properly. Use at your own risk“.

Die ist aber erst für gcc 42 vorgesehen.

Oliver

Erstens: "if (variable)" (wenn sie vom Typ "int" ist) ist völlig 
identisch zu "if (variable != 0)". Die Auswertung der Bedingung erzeugt 
ja wiederum einen Ausdruck vom Typ "int", wie soll der Compiler also für 
den gleichen Typ einmal eine Warnung generieren und das andere Mal 
nicht?

Zweitens: nein, ein Array ist was anderes als ein Zeiger.

Ich denke, du suchst eine andere Programmiersprache als C. ;-)

Ingo schrieb:
> Oder variable ist int variable[n], dann wäre das o.g. ja
> sowas:
> if (variable != NULL) bla();
>
> Gemeint ist aber eventuell das hier:
> if (variable[0] != 0) bla();

Dafür könnte es etwas geben, weil die Adresse eines solchen Arrays nie 
NULL sein kann. Manche Compiler könnten, wenn dazu aufgefordert, darauf 
hinweisen.

Statt des Compilers hilft dir evtl. ein Tool zur statischen Code 
Analyse.

Sonst such mal mit einer RegExp im Code

Ingo schrieb:
> Hallo,
>
> gibt es einen -W... Schalter, der mir bei sowas hier (wegen Faulheit zum
> Tippen) Warnungen auswirft?
>
>

1

if (variable) bla();

Warum sollte da eine Warnung kommen?

> variable kann ja int variable sein, dann sollte aber trotzdem verlangt
> werden, dass ich
>
>

1

if (variable != 0) bla();

Nein.

> schreibe. Oder variable ist int variable[n], dann wäre das o.g. ja
> sowas:
>
>

1

if (variable != NULL) bla();

Nein

>
> Gemeint ist aber eventuell das hier:
>
>

1

if (variable[0] != 0) bla();

>
> Nur kommt halt keine Warnung.

Genau.
Der Compiler kann ja nicht raten, was Du willst.
C/C++ ist (noch) nicht: WYMIWYG (what you mean is what you get).

A. S. schrieb:
> Abhilfe für Dein Problem schaffen nur statische Code-Analyse-tools und
> hohe Disziplin.

Wobei ziemlich gute tools für statische Code-Analyse heutzutage die 
Compiler selber sind.

Oliver

Ingo schrieb:
> Einige
> Variablen werden zu Arrays, natürlich überall im Code und da steht eben
> wirklich oft
> if (variable) ...
>
> Die fehlende Warnung ist wirklich schade.

Häh? Genau bei diesem Fall gibt der Compiler doch eine Warnung aus...
d.H. der Compiler macht doch bereits exakt das, was du willst?

1

#include <stdio.h>

2

int variable;

3

int main() {

4

    if (variable) printf("test");

5

}

gibt keine Warnung,
bei Änderung auf:

1

#include <stdio.h>

2

int variable[42];

3

int main() {

4

    if (variable) printf("test");

5

}

gibt's ein

1

<source>: In function 'main':

2

<source>:4:9: warning: the address of 'variable' will always evaluate as 'true' [-Waddress]

3

    4 |     if (variable) printf("test");

um die Ohren...

DerEgon schrieb:
> Nun könnte "variable" aber auch ein Funktionsparameter und keine
> statische Variable sein, und schon geht's nicht mehr.
>
>

1

> int variable[4];

2

> 

3

> void test(int *p)

4

> {

5

>   if (p)

6

>   {

7

>     //bla

8

>   }

9

> 

10

>   if (p[0])

11

>   {

12

>     //bla

13

>   }

14

> }

15

> 

16

> ...

17

> 

18

> test(variable);

19

>

Was soll hier nicht mehr gehen?

Zeiger sind "nullable-references": die Signatur sagt also klar aus, dass 
die Funktion test(int* p) mit dem inout-Parameter p auch nullptr 
akzeptiert. Das checked-pointer-idiom ist also vollkommen richtig.

Wobei Dein Code falsch ist. Es müsste heißen:

1

bool test(int* p) {

2

    if(p) {

3

        p[0] = 42;

4

        return true;

5

    }  

6

    else {

7

        // do not use p;

8

        return false;

9

    }

Wenn keine "nullable-reference" für die Funktion gemeint ist, dann muss 
man das auch schreiben:

1

void test(int& p) {

2

    p = 42;

3

}

Vielleicht hat der TO aber auch nicht verstanden, dass in den meisten 
Kontexten der Bezeichner eines Arrays zu einem Zeiger zerfällt (decay).
Aber auch das kann man sinnvoll vermeiden, in dem man das decay eben 
vermeidet.
Man sollte halt schon wissen, was man schreibt. Und der Compiler macht 
genau das, was man hinschreibt.

Wilhelm M. schrieb:
> Wenn keine "nullable-reference" für die Funktion gemeint ist, dann muss
> man das auch schreiben:

Das ist C++ (only). Gut, der TE schrieb nicht dazu, um welche Sprache es 
geht …

Wilhelm M. schrieb:
> Was soll hier nicht mehr gehen?

Das, um was es in diesem Thread eigentlich ging:

eine Warnung auch bei syntaktisch richtigem Code, wenn der TO als 
Codeautor eigentlich was ganz anders wollte, als er hingeschrieben hat.

Oliver

Oliver S. schrieb:
> Wilhelm M. schrieb:
>> Was soll hier nicht mehr gehen?
>
> Das, um was es in diesem Thread eigentlich ging:
>
> eine Warnung auch bei syntaktisch richtigem Code, wenn der TO als
> Codeautor eigentlich was ganz anders wollte, als er hingeschrieben hat.

Ok, wie ich oben schon mal sagte: "what you mean is what you get" ist 
derzeit erst für gcc Version 42 geplant.

Wobei es natürlich schon sein kann, dass statische Codeanalyse-Tools 
auch abseits der Syntax entsprechende stilistische Überprüfungen 
vornehmen können. Typischer Anwendungsfall: MISRA-Überprüfungen, bei 
denen ja sehr viele Einschränkungen angewendet werden. Ist die Frage, ob 
man sowas auch kostenlos bekommt.

Ein Kommentar schrieb:
> ich will eine Warnung bei

Ist in -Wall drin.

Ein Kommentar schrieb:
>> eine Warnung auch bei syntaktisch richtigem Code
>
> Wo wir gerade bei dem Thema sind - ich will eine Warnung bei
>
>

1

if (variable = 0) bla();

Bekommst Du, wenn variable sinnvollerweise read-only ist:

1

const int variable = <expression>;

Wilhelm M. schrieb:
> variable

heisst wohl nicht ganz umsonst so.

Oliver

Wilhelm M. schrieb:
> Bekommst Du, wenn variable sinnvollerweise read-only ist:

Die Warnung bekommst du bei "read-write"-Variablen. Man muss die 
Warnungen nur anschalten. Bei "const" ist's ein Fehler, und keine 
Warnung.

Zählererbse schrieb:
> Warnung sind zum ignorieren da

Nachdem wir im Laufe dieses Threads so viele neue und innovative 
Warnungen in den GCC eingebaut haben (Sogar rückwirkend in alte 
Versionen! Zeitmaschine!), hätte ich da noch eine radikale Idee:

Einen Schalter, dass Warnungen wie Fatale Fehler behandelt werden, damit 
man sie nicht mehr ignorieren kann.
Diesen Switch könnte man dann vielleicht "-Werror" nennen.

Oliver S. schrieb:
> Wilhelm M. schrieb:
>> variable
>
> heisst wohl nicht ganz umsonst so.

Der Name (softwaretechnische) "Variable" für ein "benanntes Objekt" ist 
historisch wie viele Dinge, will sagen, trifft also nicht mehr ganz ins 
Ziel, und hat ja je nach Kontext unterschiedliche Bedeutungen (z.B. != 
mathem. Variable).

Zudem sollten möglichst alle "Variablen" read-only sein, damit ein 
schleichender Bedeutungswechsel in ihrem Gültigkeitsbereich 
ausgeschlossen ist. Ganz besonders wichtige Kandidaten dafür sind etwa 
die Parametervariablen einer Funktion. Man braucht auch nicht der 
Meinung zu sein, dass Einführen weiterer read-only Variablen für 
errechnete Werte bringe Nachteile: der Compiler wird es entsprechend 
optimieren.

Klassiker:

1

void f(const char* name) {

2

   // ...

3

   name += 3; // <1>

4

   // ...

5

   g(name);

6

}

Ab <1> ist name eben nicht mehr der vollständige Name, sondern der 
Name-ohne-Prefix. Das ist eine Bedeutungswechsel der Variablen name.

Daher besser:

1

void f(const char* const name) {

2

   // ...

3

   const char* const basename = (name + prefixlength);

4

   // ...

5

   g(basename);

6

}

Das ist für den oftmals flüchtigen Leser des Codes wesentlich besser.

A. S. schrieb:
> Disziplin

Davon abgesehen, dass ich die Lesbarkeit bescheiden finde (wir sagen 
schließlich "Wenn a gleich 5 ist" und nicht "Wenn 5 gleich a ist"), 
hilft dir das spätestens dann nicht mehr, wenn du a und b vergleichen 
musst. Die Compilerwarnung für das einfache Gleichheitszeichen, die wohl 
mittlerweile jeder Compiler beherrscht, hilft dir dagegen auch dann 
noch.

Wilhelm M. schrieb:
> Oliver S. schrieb:
>> Wilhelm M. schrieb:
>>> variable
>>
>> heisst wohl nicht ganz umsonst so.
>
> Der Name (softwaretechnische) "Variable" für ein "benanntes Objekt" ist
> historisch wie viele Dinge, will sagen, trifft also nicht mehr ganz ins
> Ziel,

IMHO tut er das immer noch. Eine const-Variable kann zwar nicht
überschrieben werden, aber bei jeder Instanziierung einen anderen Wert
annehmen.

In der funktionalen Programmierung heißen die Dinger ebenfalls
Variablen, obwohl sie dort schon seit jeher implizit "const" sind. Der
Begriff wurde dort aus der Mathematik übernommen, wo es ebenfalls keine
Zuweisungen an Variablen gibt. x=x+1 bedeutet in der Mathematik nicht
"erhöhe x um 1", sondern ist entweder einer Gleichung oder (wie auch in
der FP) eine rekursive Definition.

Eine Anmerkung schrieb:
> Ein Bauingenieur, ...

Das hört sich so an als wäre die Arbeit der Bauingenieure equivalent zu 
Malen nach Zahlen.

Eine Anmerkung schrieb:
> Genau hier liegt das Problem.

Das Problem bei dieser Schreibweise liegt daran, dass sie aus Zeiten 
stammt, da Compiler den Fehler noch nicht gewarnt haben. Das ist 20+ 
Jahre her, aber seither hat sie sich bei einigen festgesetzt als "das 
ist so sicherer".

Warum diese Schreibweise das Problem sowieso nicht lösen kann, habe ich 
oben argumentiert. Aber du argumentierst lieber mit "Disziplin". Wir 
sind hier aber nicht bei der Armee, wo Befehle nach Disziplin ausgeführt 
werden müssen, sondern Programmierer müssen eigenständiges Denken 
anwenden. Das unterscheidet sie von Soldaten.