Forum: Compiler & IDEs Problem mit "rc5" von Peter Dannegger


von Robert Ibener (Gast)


Angehängte Dateien:

Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Simon K. (simon) Benutzerseite


Lesenswert?

Quatsch Peter. Mit der Compileroption -funsigned-char ist der Datentyp 
"char" per default unsigned.

von Robert Ibener (Gast)


Lesenswert?

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

von Robert Ibener (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Stefan E. (sternst)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Stefan E. (sternst)


Lesenswert?

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.

von Sebastian B. (mircobolle)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von mogli (Gast)


Lesenswert?

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

von Stefan E. (sternst)


Lesenswert?

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
Noch kein Account? Hier anmelden.