mikrocontroller.net

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


Autor: Robert Ibener (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quatsch Peter. Mit der Compileroption -funsigned-char ist der Datentyp 
"char" per default unsigned.

Autor: Robert Ibener (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Robert Ibener (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht 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").

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht 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.
#define s8 signed char
#define u8 unsigned char

// 32 Bit Controller
#ifdef 32_BIT
   #define s32 signed int 
#else
   #define s32 signed long
#endif

// usw.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: mogli (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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... ?

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.