Hallo C-Spezialisten, bin zwar kein "blutiger" Anfänger in C, aber auch noch nicht so weit, daß ich folgendes Problem alleine lösen kann.Deswegen bitte ich um Eure Hilfe und Euren Rat. Habe mir das Projekt "rc5" von Peter Dannegger geholt und versucht es bei mir zum laufen zu bringen.Habe nur alle "XTAL" auf "F_CPU" geändert (im Makefile vom AVR-Studio ist ja "F_CPU" schon definiert). Arbeite mit AVR Studio V. 4.15,Build 623 und GCC-Version 4.3.0 (WinAVR 20080610). Nach dem Linken/Compilieren von rc5 erhalte ich folgende Warnings: ------------------------------------------------------------------------ ../main.c:12: warning: conflicting types for built-in function 'putchar' ../main.c:19: warning: conflicting types for built-in function 'puts' cc1plus.exe: warning: command line option "-std=gnu99" is valid for C/ObjC but not for C++ AVR Memory Usage ---------------- Device: atmega8 Program: 694 bytes (8.5% Full) (.text + .data + .bootloader) Data: 24 bytes (2.3% Full) (.data + .bss + .noinit) Build succeeded with 3 Warnings... ------------------------------------------------------------------------ Frage 1: Der Compiler meckert, daß dieser Code ein C++ Code ist. Wenn ich "-std=gnu99" aus dem MAKEFILE herausnehme, so ist diese Warnung weg.So gut, so schön.Wie aber bitte kann ich feststellen, ob dieser Code ein C++ oder ein "standard" C-Code ist ?? Für mich sieht der Code eigentlich nach "standard"-C aus. Frage 2: Wie bringe ich die nun 2 verbleibenden Warnings weg ?? Frage 3: Wenn ich (nach make clean) einmal auf "Build" = F7 im AVR-Studio drücke, so erscheinen eben obige Warnings.Wenn ich noch einmal auf Build drücke, so sind alle Warnings weg : --------------------------------------- >> Build succeeded with 0 Warnings... --------------------------------------- Ist das ein Feature oder ein Bug vom AVR Studio ?? Hoffe, daß mir von Euch geholfen wird, obige Probleme zu lösen. Liebe Grüße aus Wien Robert
Das C++ kommt daher, daß mein Editor Filenamen groß schreibt, also *.C. Mit dem Schalter -xc kann man es dem Compiler abgewöhnen. Oder umbenennen in *.c Die Warnungen kommen, weil das Beispiel mit nem älteren WINAVR gemacht wurde. Die neueren mäkeln auch an Stellen rum, wo es nichts zu mäkeln gibt: Für ASCII-Strings akzeptieren sie nur char und nichts anderes. Ich hatte Zeichen immer als unsigned definiert, weil es ja auch Zeichen jenseits der 127 gibt, jedoch keine negative Zeichen. Negative Zeichen sind zwar ausgemachter Schwachsinn, aber da die Compilerbauer es nun mal so wollen, muß man sich entweder fügen oder diese Warnungen ignorieren. Peter
Quatsch Peter. Mit der Compileroption -funsigned-char ist der Datentyp "char" per default unsigned.
Hallo Peter, das mit der Groß-Schreibung stimmt leider nicht.Meine (Deine) Files habe ich alle in Klein-Schreibung umgewandelt (leider nicht in den angehängten ZIP-Files ! Hallo Simon, habe ich auch ausprobiert, schafft leider bei meinem Problem auch nicht aus der Welt. An Beide: Habe ein externes MAKEFILE mit dem Programm "MFile" erstellt, am AVR-Studio eingestellt, daß es ein externes MAKEFILE gibt und damit compiliert.Obwohl auch das mit MFile erstellte MAKEFILE die Compileroption "-std=gnu99" enthält, kommt KEIN Hinweis, daß diese Option bei diesem Code nicht verwendet werden kann. ---> EIGENARTIG <--- Noch zu den 2 restlichen Warnings "conflicting types ....": Was kann ich tun, um diese zu eliminieren ?? Ignorieren will ich sie nicht ! Danke inzwischen für Eure Antwort. Robert
Hallo Peter, ich muß mich bei Dir entschuldigen: Nach Kontrolle der diversen Files auf Großbuchstaben habe ich doch tatsächlich ein File übersehen, wo der ERSTE Buchstabe in Groß-Schreibung war.Alle *.c waren klein geschrieben! Nach Änderung des ersten Buchstabens auf Klein-Schreibung kommt jetzt keine C++-Warnung mehr. Übrigens : Die Compiler-Option "-funsigned-char" ist bei mir im Makefile drinnen. Frage: Hat diese Compiler-Option höhere Priorität als eine Definition im Code? Wenn ich also "char" schreibe, ist dieses "char" dann laut Compiler-Option automatisch "unsigned char" ? Bleiben nur noch die 2 warnings zu lösen. Grüße Robert
Robert Ibener wrote: > Groß-Schreibung war.Alle *.c waren klein geschrieben! Nach Änderung des > ersten Buchstabens auf Klein-Schreibung kommt jetzt keine C++-Warnung > mehr. Wie gesagt "-xc" häts auch getan. > Übrigens : Die Compiler-Option "-funsigned-char" ist bei mir im Makefile > drinnen. Wozu ? Damit gräbst Du Dir nur selbst ne Fallgrube, wenn mit char gerechnet wird und default signed angenommen wird. > Bleiben nur noch die 2 warnings zu lösen. Benenne mal alle puts/putchar um, z.B. in uputs/uputchar. Das mit char war was anderes (betrifft nur Pointer). Peter
Peter Dannegger wrote: > Damit gräbst Du Dir nur selbst ne Fallgrube, wenn mit char gerechnet > wird und default signed angenommen wird. Wenn du im Source nur "char" schreibst und dann davon ausgehst, dass das signed ist, gräbst du dir eine noch viel größere Fallgrube. Die Signedness von char ist nämlich nicht vorgegeben. Auch ohne explizite Compiler-Option kann das per default unsigned sein. Wenn du also ein char hast, dass unbedingt signed sein muss, dann muss man es auch so hinschreiben ("signed char").
Stefan Ernst wrote: > Wenn du also ein > char hast, dass unbedingt signed sein muss, dann muss man es auch so > hinschreiben ("signed char"). Kann ja auch fremder Text sein, den man übernommen hat. Man sieht es jedenfalls sehr häufig, daß int oder char als Schleifenvariable genommen wird und auf >=0 getestet wird. Gibt bei unsigned ne super Endlossschleife. Daher vermeide ich es, default-Einstellungen umzudefinieren. Peter
Peter Dannegger wrote:
> Daher vermeide ich es, default-Einstellungen umzudefinieren.
Der Knackpunkt ist ja aber gerade, dass es bei char keine allgemein
gültige default-Einstellung gibt.
Du kannst auch auf fremden Code treffen, wo der Programmierer immer nur
char schreibt und sich darauf verlässt, dass das dann unsigned ist, weil
bei seinem Compiler das eben der Default ist.
Code, der bei char von einer bestimmten Signedness ausgeht (egal ob
signed oder unsigned) ist eigentlich fehlerhaft!
Nichtsdestotrotz hast du aber natürlich Recht damit, dass bei eigenem
Code das -funsigned-char nicht wirklich Sinn hat. Man braucht es
eigentlich nur für genau den Fall oben.
Stefan Ernst wrote: > Peter Dannegger wrote: > >> Daher vermeide ich es, default-Einstellungen umzudefinieren. > > Der Knackpunkt ist ja aber gerade, dass es bei char keine allgemein > gültige default-Einstellung gibt. > Du kannst auch auf fremden Code treffen, wo der Programmierer immer nur > char schreibt und sich darauf verlässt, dass das dann unsigned ist, weil > bei seinem Compiler das eben der Default ist. > > Code, der bei char von einer bestimmten Signedness ausgeht (egal ob > signed oder unsigned) ist eigentlich fehlerhaft! > > Nichtsdestotrotz hast du aber natürlich Recht damit, dass bei eigenem > Code das -funsigned-char nicht wirklich Sinn hat. Man braucht es > eigentlich nur für genau den Fall oben. Um solchen Diskussionen aus dem Weg zu gehen, sollte man eindeutige Typen definieren. z.B.
1 | #define s8 signed char
|
2 | #define u8 unsigned char
|
3 | |
4 | // 32 Bit Controller
|
5 | #ifdef 32_BIT
|
6 | #define s32 signed int
|
7 | #else
|
8 | #define s32 signed long
|
9 | #endif
|
10 | |
11 | // usw.
|
Sebastian B. wrote: > Um solchen Diskussionen aus dem Weg zu gehen, sollte man eindeutige > Typen definieren. Nein sollte man nicht. Viel lieber sollte man die bereits vorhandenen Typen aus stdint.h benutzen.
>Der Knackpunkt ist ja aber gerade, dass es bei char keine allgemein >gültige default-Einstellung gibt. ^--- Dann ist doch aber der "C" Compiler, Implementierung oder wie auch immer, nicht richtig. Denn gleicher Code muss doch zu den gleichen Ergebnisen führen ??! (prinzipiel -- wenn man das "maschinen" abhängige aussen vor lässt) Bzw. das es unsigned und signed Char gibt ist logisch. Aber das "fallback" (auf un/signed) wenn man nur die Breite angibt, müsste doch immer gleich sein... ?
mogli wrote: > Bzw. das es unsigned und signed Char gibt ist logisch. > Aber das "fallback" (auf un/signed) wenn man nur die Breite angibt, > müsste doch immer gleich sein... ? Nein. Der C-Standard überlässt die Entscheidung dem Compiler, ob ein plain char signed oder unsigned ist.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.