Compiler meckert nicht, obwohl er müsste

[öhm (Gast)]

Guten Tag!


Ich habe wieder mal eine ganz kurze Frage lol:

Ich habe in meinem Projekt main.c, test.c Dateien mit der dazugehörigen 
header Datei test.h.

Nun habe ich in meiner main.c vergessen die test.h einzubinden und führe 
in
meiner main.c Funktionen aus, die in der test.h deklariert sind.

Erstaunlicherweise hat der Compiler nicht gemekert. Das Projekt wurde 
compiliert und konnte ausgeführt werden. (Allerdings traten 
verständlicherweise seltsame Effekte auf. Variablenwerte wurden 
überschrieben usw...)

Ich habe lange nicht verstanden was da los ist, bis ich bemerkt habe, 
dass ich #include test.h  auskommentiert hatte.

Wie ist es möglich, dass das Projekt compiliert werden konnte und sogar 
teilweise funktioniert hat???

[Johann L. (gjlayde)]

Deine Freunde sind

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

[Karl H. (kbuchegg)]

öhm schrieb:

> Nun habe ich in meiner main.c vergessen die test.h einzubinden und führe
> in
> meiner main.c Funktionen aus, die in der test.h deklariert sind.

Soweit so gut.

> Erstaunlicherweise hat der Compiler nicht gemekert.

Er ist auch nicht dazu verpflichtet.
Dieser Fall ist kein Fehler (nur die sind fakultativ). Wenn der Compiler 
nett ist, dann schmeisst er eine Warnung. Wenn du allerdings den 
Warning-Level tief genug ansetzt, dann eben nicht.

> Wie ist es möglich, dass das Projekt compiliert werden konnte und sogar
> teilweise funktioniert hat???

Weil in dem Fall, in dem der Compiler keinen Protoypen sieht, er mit 
Standardannahmen arbeiten muss. Er kann eine Warnung geben. Er kann - 
aber er muss nicht.

Warnungen einschalten und den Warning Level möglichst hoch setzen.

[öhm (Gast)]

Karl Heinz Buchegger schrieb:
> Warnungen einschalten und den Warning Level möglichst hoch setzen.

Hmm ok. Hab ich jetzt gemacht.


Hätte vermutet, dass ohne eingefügtes #include "test.h"  garnix mehr 
funktioniert. Der GCC halt mal wieder.


Danke euch.

[Jörg W. (dl8dtl) (Moderator)]

öhm schrieb:
> Der GCC halt mal wieder.

C halt mal wieder.  “All functions return an int and take an
arbitrary number of arguments” ist das uralte Paradigma des
ursprünglichen K&R-Cs, das dahinter steht. Implizit war dann
selbstverständlich ein int auch gleich identisch zu einem
x-beliebigen Zeiger.

Hat schon so ihre Altlasten, die Sprache. :)  (Bevor unser
beliebter C-Hasser jetzt wieder kommt: derartige Paradigmen
entstammen natürlich durchaus der Sichtweise eines
Assemblerprogrammierers.)

[Karl H. (kbuchegg)]

Jörg Wunsch schrieb:
> öhm schrieb:
>> Der GCC halt mal wieder.
>
> C halt mal wieder.  “All functions return an int and take an
> arbitrary number of arguments” ist das uralte Paradigma des
> ursprünglichen K&R-Cs, das dahinter steht.

Mit der Ergänzung "we trust the programmer to know how many arguments a 
function takes and what their data types are, paired with the knowledge 
of the implicite propagation rules."


> Hat schon so ihre Altlasten, die Sprache. :)

:-)
Wobei an dieser Stelle die Konservativität des Gremiums schon 
grenzwertig ist. Keinen Protoyp im Scope zu haben sollte ein Fehler 
sein. Selbst dann wenn ältere Programme dann nicht mehr fehlerfrei 
compilieren. Sie können von einer Code-Modernisierung nur gewinnen. Oder 
kennt heutzutage noch irgendwer irgendwen, der das Hasardspiel eingeht, 
ohne Protoypen zu compilieren?

>  (Bevor unser
> beliebter C-Hasser jetzt wieder kommt: derartige Paradigmen
> entstammen natürlich durchaus der Sichtweise eines
> Assemblerprogrammierers.)

:-)
Und er wird sich schwer tun, selbst K&R C daraus einen Strick zu drehen.

[Lacsap (Gast)]

> Keinen Protoyp im Scope zu haben sollte ein Fehler sein.
Das zeigt uns wieder, dass bei C aufzuhören ein Fehler ist. Besser wäre 
ein D, F, E, ..., J. :-D

[Johann L. (gjlayde)]

Karl Heinz Buchegger schrieb:
> Keinen Protoyp im Scope zu haben sollte ein Fehler sein.

Was spricht dagegen, die entsprechende Option zu setzen?

Lacsap schrieb:
> Das zeigt uns wieder, dass bei C aufzuhören ein Fehler ist. Besser wäre
> ein D, F, E, ..., J. :-D

Hat schonmal jemand mit dem neuen D-Frontend im GCC (GDC) rumgespielt?

http://de.wikipedia.org/wiki/D_(Programmiersprache%29

[Karl H. (kbuchegg)]

Johann L. schrieb:
> Karl Heinz Buchegger schrieb:
>> Keinen Protoyp im Scope zu haben sollte ein Fehler sein.
>
> Was spricht dagegen, die entsprechende Option zu setzen?

Das sie nicht vom Standard gefordert ist.
Wenn ein Compiler das anbietet - schön. Aber er muss nicht. Und genau da 
liegt das Problem. Es gibt IMHO keinen vernünftigen Grund, so ein 
Verhalten NICHT in den offiziellen Standard mit aufzunehmen.

[Jörg W. (dl8dtl) (Moderator)]

Karl Heinz Buchegger schrieb:
> Das sie nicht vom Standard gefordert ist.

Mir ist so, als wären Prototypen bei C99 Pflicht.

Allerdings ist -std=c99 (oder gnu99) halt nach wie vor nicht die
Voreinstellung, sondern immer noch -std=gnu89.

[Karl H. (kbuchegg)]

Jörg Wunsch schrieb:
> Karl Heinz Buchegger schrieb:
>> Das sie nicht vom Standard gefordert ist.
>
> Mir ist so, als wären Prototypen bei C99 Pflicht.

Fast.
Eine Deklaration ist Pflicht geworden. Aber es muss kein kompletter 
Protoyp sein. D.h.

int foo();

int main() {
  int i = foo(5); 
}

ist ok. Der Deklarationspflicht ist genüge getan.

Warum man das nicht gleich in Richtung Prototyp geändert hat? Ich hab 
keine Ahnung.
Lustigerweise wird nämlich für variadische Funktionen ein Protoyp 
gefordert oder es gibt 'undefined behaviour'

[Johann L. (gjlayde)]

Karl Heinz Buchegger schrieb:
> Johann L. schrieb:
>> Karl Heinz Buchegger schrieb:
>>> Keinen Protoyp im Scope zu haben sollte ein Fehler sein.
>>
>> Was spricht dagegen, die entsprechende Option zu setzen?
>
> Das sie nicht vom Standard gefordert ist.
> Wenn ein Compiler das anbietet - schön. Aber er muss nicht.
> Und genau da liegt das Problem. Es gibt IMHO keinen vernünftigen
> Grund, so ein Verhalten NICHT in den offiziellen Standard mit
> aufzunehmen.

Rant : Pragmatismus = 1 : 0

:-)