makefile warnungen abschalten

leluno schrieb:
> ich habe bei meinen gcc programmen inzwischen eine solche Vielzahl von
> Warnungen, dass die Suche nach den errors erheblich erschwert wird.
>
> Wie kann ich die Warnungen ganz abschalten

Fragst du dann als nächstes, wie du den Virenscanner deaktivieren 
kannst, weil er dich dauernd damit nervt, daß er irgendwelche Viren 
gefunden hat?

Das wäre genauso, als wenn man in der Schule die Prüfungsfragen 
einfacher gestaltet. Klar hebt man dadurch den Notendurchschnitt an und 
die Schule steht besser da (PISA läßt grüßen), aber die Schüler werden 
deshalb nicht klüger.

Vielen Dank für die hilfreichen Antworten..
 Ich habe über Seiten Warnungen wie folgt:


197: warning: pointer targets in passing argument 1 of 'GUI_Text' differ 
in signedness
heizung.h:198: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:205: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:205: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:230: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:230: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:231: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:231: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:232: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:232: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:233: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:233: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:236: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:236: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:237: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:237: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:238: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:238: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:239: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:239: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:241: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:241: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:242: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:242: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:243: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h:243: warning: pointer targets in passing argument 1 of 
'GUI_Text' differ in signedness
heizung.h: At

dass hier irgendwo ein unsigned Wert übergeben wird obwohl -warum auch 
immer - ein signed Typ verlangt wird, weiß ich auch. Der Fehler ist von 
mir nicht zu finden. Interessiert mich auch nicht weiter, weil die 
Funktion gut funktioniert.

Muss ich mich von gcc nun wirklich ständig über das Vorhandensein dieses 
dämlichen Fehlers belehren lassen, oder kann man das irgendwo 
abschalten?


Dass ich eigentlich sowieso zu blöde bin, ist mir inzwischen völlig 
bewusst. Es muss daher nicht mit jedem Kommentar ausdrücklich wiederholt 
werden.

leluno schrieb:
> Muss ich mich von gcc nun wirklich ständig über das Vorhandensein dieses
> dämlichen Fehlers belehren lassen, oder kann man das irgendwo
> abschalten?

Nein, mußt du nicht. Nur hartnäckig bleiben und EINMAL den Fehler 
finden. Er ist nunmal da und man kann ihn sicher auch finden. Ich denke 
mal, bestimmt auch mit Hilfe des Forums. Aber einfach ignorieren ist die 
denkbar schlecheste Lösung. Auch wenn du jetzt keine Auswirkung spürst, 
irgendwann wird dir das bestimmt in einem anderen Zusammenhang uf die 
Füße fallen.

kann es sein das du den quelltext in eine *.h datei schreibst?

> heizung.h:242: ...
> heizung.h:243: ...

das diese Meldung für verschiende Zeilen in einem header kommt, ist sehr 
merkwürdig.

vielleicht noch eine Meinung vom Nicht-Experten: Beim ersten make mit 
-Wextra dachte ich noch "der spinnt doch, der gcc, die Warnungen bringe 
ich nie raus", aber die Fleißarbeit hat sich wirklich gelohnt. Dabei 
sind durchaus auch echte Fehler aufgekommen. Mit "-O" gibt's auch noch 
meine Lieblings-Warnung "'foo' may be used uninitialized in this 
function", aber man kann den Assembler-Output trotzdem noch lesen.

Ich spendiere auch noch ein "-pedantic", was haltet ihr davon?

-pedantic kann man aus Spaß mal nutzen, um zu verstehen, was das alles 
anmmeckert. Das erlaubt nur striktes ISO-C, die Einschränkung will man 
aber nicht immer haben.

Oliver

Ich wäre ja schon dankbar, wenn mir jemand sagen würde, dass man die 
Warnungen aus pädagogischen Gründen nicht abschalten kann.

Die beanstandete Funktion sieht so aus:

//==================================================
void GUI_Text(uint8_t *str)
{
  uint8_t TempChar;
    do
    {
        TempChar = *str++;
        if(TempChar<' '||TempChar>130)return;

        PutChar(TempChar);

           curposx =curposx+ f_width;
       if(frame)curposx++;
 //relposx=relposx+ f_width;
    }
    while ( *str != 0 );
}

leluno schrieb:
> Ich wäre ja schon dankbar, wenn mir jemand sagen würde, dass man die
> Warnungen aus pädagogischen Gründen nicht abschalten kann.

Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die 
Warnung abschalten kann, wenn du das Problem in deinem Code behoben 
hast.

Denn ja, man kann die abschalten...

Oliver

mit

void GUI_Text(uint8_t str*)
...

ist die Warnung tatsächlich verschwunden. Vielen Dank für die 
Untersützung.

Oliver schrieb:
> Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die
> Warnung abschalten kann, wenn du das Problem in deinem Code behoben
> hast.
>
> Denn ja, man kann die abschalten...
>
> Oliver

Nachdem der Fehler jetzt behoben ist...

leluno schrieb:
> void GUI_Text(uint8_t *str)

Für Zeichen ist char da. Welchen speziellen Grund hast du, stattdessen 
uint8_t zu verwenden?

leluno schrieb:
> Oliver schrieb:
>> Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die
>> Warnung abschalten kann, wenn du das Problem in deinem Code behoben
>> hast.
>>
>> Denn ja, man kann die abschalten...
>>
>> Oliver
>
> Nachdem der Fehler jetzt behoben ist...

Aber nur, wenn du versprichst, hier immer erst nachzufragen. bevor du 
abschaltest ;)

Mit -Wno-xxxxxxxx lässt sich gezielt jede Warnung abschalten. Genaures 
dazu steht in der gcc-Doku  - und aus pädagogischen Gründen liest du das 
bitte selber nach. Denn solche Infos in der Doku zu finden und zu lesen 
ist auch eine der unabdingbaren Grundvoraussetzung...

Oliver

Peter Dannegger schrieb:
> Man muß nun leider mit diesem Schwachsinn leben und alle Zeichen als
> char anlegen, selbst int8_t ist nicht erlaubt.

danke für diese Erklärung. der code wurde aus einem ARM-Projekt kopiert. 
Da gelten möglicherweise andere Regeln

Peter Dannegger schrieb:
> leluno schrieb:
>> 197: warning: pointer targets in passing argument 1 of 'GUI_Text' differ
>> in signedness
>
> Diese Warnung rührt daher, daß in grauen Vorzeiten Zeichen als char
> definiert wurden und sich niemand traut, das mal richtig zu biegen, also
> wenigstens auch unsigned char oder uint8_t zuzulassen.

Es gibt nichts geradezubiegen. char ist für Zeichen, PUNKT!

> Negative Zeichen sind allerdings Schwachsinn und verhindern z.B. eine
> Umwandlung von ASCII-Umlauten in LCD-Umlaute, weil char >127 nicht geht.

Wie bei so ziemlich jeder Sprache muß man halt an der einen 
Schnittstelle, an der es zur Hardware geht, vom Zeichentyp in einen 
entsprechenden Integer-Typ konvertieren. Warum damit so viele Leute ein 
Problem haben, verstehe ich ehrlich gesagt nicht.

> Man muß nun leider mit diesem Schwachsinn leben und alle Zeichen als
> char anlegen, selbst int8_t ist nicht erlaubt.

Das ist ein ganz normales Konzept in der Programmierung.

Rolf Magnus schrieb:
> Das ist ein ganz normales Konzept in der Programmierung.

Zeichen sind char, einverstanden.
Wenn man aber Zeichen so verwenden möchte, daß man auch den Zeichensatz 
ausnutzt, dann muß man erst nach uint8_t casten, was ja per Definition 
gar kein Zeichen ist? Und das nennst du normal?

Es ist nun mal so, das kann man nicht ändern, aber normal ist es 
trotzdem nicht :-)

leluno schrieb:
> der code wurde aus einem ARM-Projekt kopiert.
> Da gelten möglicherweise andere Regeln

Nein, da gelten die selben Regeln. Allerdings waren (sehr viel) ältere 
gcc's da etwas großzügiger, und haben an solchen Stellen nicht gewarnt. 
Wenn das Projekt also schon älteren Datums ist, ließ sich das zu seiner 
Enstehungszeit wohl warnungsfrei compilieren. Richtig wars deshalb aber 
nicht.

Oliver

GCC schrieb:
> Rolf Magnus schrieb:
>> Das ist ein ganz normales Konzept in der Programmierung.
>
> Zeichen sind char, einverstanden.
> Wenn man aber Zeichen so verwenden möchte, daß man auch den Zeichensatz
> ausnutzt, dann muß man erst nach uint8_t casten, was ja per Definition
> gar kein Zeichen ist?

Warum sollte man das müssen? char hat (mindestens) 8 Bit, und die kann 
ich voll nutzen, völlig egal, wie der darunterliegende Integer-Typ 
aussieht. Der interessiert mich gar nicht.

Peter Dannegger schrieb:
> Michael Reinelt schrieb:
>> Alle (mir bekannten) char-funktionen arbeiten problemlos mit dem vollen
>> Bereich 0..255 (oder -128..127, je nachdem)
>
> Na da bin ich ja mal gespannt, was eine Zeichensatztabelle auf dem GLCD
> ausgibt, wenn Du mit dem Index -128 drauf zugreifst.

Wie schon gesagt: An der einen Stelle, wo man das ganze an die Hardware 
übergibt, also in deinem Fall in putchar, macht man dann einen uint8_t 
draus. Es wäre in anderen Sprachen in der Regel auch nicht anders. Da 
reicht nur ein einfacher Cast meist nicht, sondern es gibt extra eine 
Funktion dafür, die man aufrufen muss.

Peter Dannegger schrieb:
> Klaus Wachtler schrieb:
>> Wer char ohne cast als Index nimmt
>
> Die standard Antwort des C-Programmierers: "Nimm einen Cast mehr".

Wenn du char richtig verwendest, hast du an einer einzigen Stelle, 
nämlich der low-level-Schnittstelle einen Cast. Es ist nicht so, als ob 
du dafür deinen kompletten Code mit Casts spicken müßtest. Das passiert 
erst dann, wenn du überall uint8_t statt char verwendest. Dann hagelt es 
eben wie beim Ursprungsposter auf einmal massenhaft Warnungen, wenn man 
mit String- oder Zeichenkonstanten oder Standard-Stringfunktionen 
arbeitet. Da bräuchte man dann tatsächlich jede Menge Casts, um den 
Compiler ruhigzustellen.