mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik [AVR Studio 6] Funktionen werden auch ohne include der *.h Datei übernommen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Jens G. (meinnameisthase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo miteinander,

ich habe ein Problem mit dem AVR Studio 6. Mein Programm ist im Aufbau 
und der erste Code läuft schon auf der Hardware.

Jedoch fällt mir gerade auf - dass ich neue Funktionen - die nur in der 
*.c Datei definiert sind (und nicht in der*.h) problemlos in der main.c 
benutzen kann. Das komische daran ist, funktioniert auch bei entfernten 
#include <> in der main.

Ist hier an der Linker-Einstellung noch was zu ändern? Hatte jemand 
schon mal das gleiche Problem?

Jens

: Verschoben durch Moderator
Autor: Thomas W. (diddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe dein "Problem" nicht, zumal du "problemlos" geschrieben 
hast.


Prototypen in der .h sind nicht zwingend.
Der Compiler sollte halt eine Warning generieren.


Problem:

Es wird halt ein Funktionstypen Set angenommen vom Compiler, aufgrund 
des Aufruf der Funktion.

Besser ist halt, wenn die Prototyp Declaration da ist in der include 
Datei, denn dann kann die Funktion nicht "falsch" benutzt werden.

Autor: fop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Prototypen der Funktionen müssen dem Compiler zum Zeitpunkt des 
Aufrufs bekannt sein. Das sind sie natürlich auch, wenn in einer Datei 
zunächst die Implementierung der Funktion kommt und danach erst ihr 
Aufruf.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas W. schrieb:
> Es wird halt ein Funktionstypen Set angenommen vom Compiler, aufgrund
> des Aufruf der Funktion.

Nicht ganz.

Es wird eine prototypenlose Funktionsdeklaration angenommen, “all the 
world is an int”. Eine solche Funktion entspricht dem, was in C vor der 
1989er Standardisierung üblich war: die Funktion gibt einen "int" zurück 
(von dem üblicherweise angenommen wird, dass man ihn ggf. auch in einen 
gültigen Objektzeiger wandeln kann), und sie nimmt eine unbestimmte 
Anzahl von Argumenten.

Das ist halt der kleinste gemeinsame Nenner, wie er bis vor 30 Jahren 
üblich war. Seither sollte man diesen vermeiden und stattdessen eine 
explizite Funktionsdeklaration parat haben.

Der Linker wiederum interessiert sich nur dafür, ob er alle 
unreferenzierten Symbole irgendwie auffinden kann, entweder in bereits 
gelinkten Objektmodulen, oder aus einer Bibliothek. Da die gelinkten 
Objektmodule natürlich die Implementierung aller erforderlichen 
Funktionen enthalten, funktioniert es am Ende alles.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens G. schrieb:
> Jedoch fällt mir gerade auf - dass ich neue Funktionen - die nur in der
> *.c Datei definiert sind (und nicht in der*.h) problemlos in der main.c
> benutzen kann. Das komische daran ist, funktioniert auch bei entfernten
> #include <> in der main.

Wenn du das angemeckert haben willst: compilieren mit

-Werror=missing-prototypes -Werror=strict-prototypes

bzw. nur als Warnung:

-Wmissing-prototypes -Wstrict-prototypes

Außerdem sollte es heißen #include "modul.h" statt #include <modul.h> 
denn es handelt sich dabei vermutlich nicht um einen System-Header wie 
etwa math.h oder stdlib.h.

Autor: Jens G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen dank erstmal für die schnelle Hilfe.

Das sind gute Hinweise, doch trifft es die zusätzliche 
Compilereinstellung mit Warnings ganz gut. Sowas habe ich gesucht.

@ Johann L. richtig, war ein Flüchtigkeitsfehler. Meine selbst 
geschriebenen Module sind mit #include "xyz.h" eingebunden.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens G. schrieb:
> Das sind gute Hinweise, doch trifft es die zusätzliche
> Compilereinstellung mit Warnings ganz gut. Sowas habe ich gesucht.

Die müssten eigentlich in -Wall mit drin sein. Das sollte man dem GCC 
immer mitgeben.

Autor: Egonwalter M. (heiner1234)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Die müssten eigentlich in -Wall mit drin sein. Das sollte man dem GCC
> immer mitgeben.

leider nicht - bei meinen avr-gcc Version 4.3.3 habe ich immer -Wall 
angegeben, er hat aber nie wg.  Prototypen gemeckert - ich hatte z.B 
eine Funktion deklariert "uint8_t test()" (in der Definition stand dann 
natürlich "uint8_t test(void)" - da hat das -Wall nichts gebracht, aber 
mit der

Johann L. schrieb:
> -Werror=missing-prototypes -Werror=strict-prototypes
>
> bzw. nur als Warnung:
>
> -Wmissing-prototypes -Wstrict-prototypes

hat der Compiler dieses fehlende "void" in der Deklaration gemeldet...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-Wall -Wextra

Autor: Arno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egonwalter M. schrieb:
> Jim M. schrieb:
>> Die müssten eigentlich in -Wall mit drin sein. Das sollte man dem GCC
>> immer mitgeben.
>
> leider nicht - bei meinen avr-gcc Version 4.3.3 habe ich immer -Wall
> angegeben, er hat aber nie wg.  Prototypen gemeckert

Ist das auch abhängig vom gewählten Standard? Wenn ich das richtig 
verstehe, sind Funktionsprototypen ja noch nicht so alt wie C als 
Programmiersprache...

MfG, Arno

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arno schrieb:
> Wenn ich das richtig verstehe, sind Funktionsprototypen ja noch nicht so
> alt wie C als Programmiersprache.

Sie sind aber so alt, wie die Standardisierung von C überhaupt. :) Sie 
wurden mit ANSI C89 bzw. ISO C90 (was das gleiche ist) eingeführt.

Die Option für Prä-C89-Code heiß/hieß "-traditional". Die benutzt wohl 
niemand mehr.

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.

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