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
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.
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.
