Ich verstehe die Welt nicht mehr - C Springt nicht in Funktion WTF?

[Frank (Gast)]

#include <stdio.h>
#include <stdlib.h>

double y1(double x);

int main()
{
    y1(4);
    return 0;
}

double y1(double x){
    printf("fjjfeifeifj");
    return 5;
}

Wieso in aller Welt gibt mir hier C keine Ausgabe fjjfeifeifj?
Kann das irgendjemand verstehen?

[Zeilenvorschub (Gast)]

Gib mal ein Linefeed (\n) mit aus.

[Dr. Sommer (Gast)]

Unter POSIX Systemen gibt es bereits eine Funktion namens "y1", und die 
rufst du auf.

"The y0() and y1() functions return Bessel functions of x of the second 
kind of orders 0 and 1, respectively."

[Frank (Gast)]

Dr. Sommer schrieb:
> Unter POSIX Systemen gibt es bereits eine Funktion namens "y1", und die
> rufst du auf.

AHAA!
Vielen dank!

[Dirk B. (dirkb2)]

Dr. Sommer schrieb:
> Unter POSIX Systemen gibt es bereits eine Funktion namens "y1", und die
> rufst du auf.

Muss da nicht der Linker schimpfen?
Und sollte das nicht nur passieren, wenn die mlib mit eingebunden wird?

[Johann L. (gjlayde)]

y1 auf der libm wird nur dann verwendet, wenn nicht bereits eine 
Implementierung vorliegt -- was im im obigen Beispiel der Fall ist.

Jedenfalls ist das das Verhalten von GNU ld, von dessen Verwendung man 
beim Einsatz von GCC wohl ausgehen darf.

[Rolf Magnus (Gast)]

Dirk B. schrieb:
> Dr. Sommer schrieb:
>> Unter POSIX Systemen gibt es bereits eine Funktion namens "y1", und die
>> rufst du auf.
>
> Muss da nicht der Linker schimpfen?
> Und sollte das nicht nur passieren, wenn die mlib mit eingebunden wird?

Nein, denn y1 ist bereits im gcc selbst implementiert und braucht daher 
gar keine libm.
Wenn man die eigene Forward-Deklaration weglässt, kommt dann auch:

Warnung: Unverträgliche implizite Deklaration der eingebauten Funktion 
»y1« [standardmäßig aktiviert]

Johann L. schrieb:
> y1 auf der libm wird nur dann verwendet, wenn nicht bereits eine
> Implementierung vorliegt -- was im im obigen Beispiel der Fall ist.

Richtig. Es liegt die vor, die der Compiler schon mitbringt.
Es scheint sich um irgendeine Erweiterung zu handeln, daß er die 
bevorzugt. Wenn man dem Compiler z.B. -ansi oder -std=c99 mitgibt, nutzt 
er die vom Benutzer definierte Funktion.

[X-X (Gast)]

Dr. Sommer schrieb:
> "The y0() and y1() functions return Bessel functions of x of the second
> kind of orders 0 and 1, respectively."

Kommt denn keine Warnung wenn man so etwas neu definiert?

[(prx) A. K. (prx)]

X-X schrieb:
> Kommt denn keine Warnung wenn man so etwas neu definiert?

Kommt nicht, sollte m.E. aber.

[X-X (Gast)]

A. K. schrieb:
> X-X schrieb:
>> Kommt denn keine Warnung wenn man so etwas neu definiert?
>
> Kommt nicht, sollte m.E. aber.

Du musst also jeden deiner Funktionsaufrufe gegen jeden in allen 
zulinkbaren libs evtl. vorhandenen Funktionsnamen gegenchecken um das 
Problem zu vermeiden?

Das wäre doch noch nicht einmal in der eigenen IDE portabel da der 
Sourcecode Projektabhängig wird.

[(prx) A. K. (prx)]

X-X schrieb:
> Du musst also jeden deiner Funktionsaufrufe gegen jeden in allen
> zulinkbaren libs evtl. vorhandenen Funktionsnamen gegenchecken um das
> Problem zu vermeiden?

Nein. Denn einen Konflikt mit Libs und dem Linker besteht hier nicht, 
wie Rolf bereits dargelegt hat. Diese (Pseudo-)Funktionen sind im 
Compiler integriert und werden direkt als Code erzeugt.

Schlimmer: Du musst theoretisch alle deine Funktionen gegen solche 
Compiler-Intrinsics checken. Und dazu erst einmal wissen, welche es 
überhaupt gibt. Oder wie skizziert auf Standard schalten, also 
beispielsweise -std=c99, was freilich auch unerwünschte Nebeneffekte 
hat.

In vielen Fällen merkst du das jedoch, weil die Signatur deiner Funktion 
nicht zur internen Funktion passt, und du eine entsprechende Meldung 
kriegst. Hier allerdings passt sie.

[X-X (Gast)]

A. K. schrieb:
>> Kommt denn keine Warnung wenn man so etwas neu definiert?
> Nein.
Ist das bei allen compilern so oder GCC spezifisch?

>Denn einen Konflikt mit Libs und dem Linker besteht hier nicht,

wäre mir ziemlich egal ob so etwas mit irgendeiner reinen Lehre konform 
geht.

> In vielen Fällen merkst du das jedoch, weil die Signatur deiner Funktion
> nicht zur internen Funktion passt

Ist aber reine Glückssache.

> Schlimmer: Du musst theoretisch alle deine Funktionen gegen solche
> Compiler-Intrinsics checken.

warum macht der Compiler das nicht selbst?

> Und dazu erst einmal wissen, welche es überhaupt gibt.

Was er ja weiß, meiner Meinung nach schwer zumutbar da leicht zu 
verhindern.

[X-X (Gast)]

Noch ne kurze Frage als "C Halbtagsexperte"

Hab bei meinem Compiler mal die Funktion double asin(double x); 
definiert.

Wenn ich die Ansi math lib im Projekt auswähle (nennt man das 
dazulinken) bekomme die Fehlermeldung:

asin identifier redefined

Ist das Problem für mich damit erledigt?

[Johann L. (gjlayde)]

A. K. schrieb:
> Diese (Pseudo-)Funktionen sind im
> Compiler integriert und werden direkt als Code erzeugt.

I.d.R aber nur bei bekanntem Argument, ansonsten kann der Compiler da 
auch nichts richten, etwa wie bei den Bessel-Funktionen oben.

> Schlimmer: Du musst theoretisch alle deine Funktionen gegen solche
> Compiler-Intrinsics checken. Und dazu erst einmal wissen, welche es
> überhaupt gibt. Oder wie skizziert auf Standard schalten, also
> beispielsweise -std=c99, was freilich auch unerwünschte Nebeneffekte
> hat.

Möglich ist auch -fno-builtin oder -fno-builtin-y1.  Die Builtins im GCC 
sind dokumentiert, die unterstützen Builtins jedoch abhängig von der 
GCC-Version.

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html