Probleme mit Return

es könnte sein dass du in dem programm wo es nicht funktioniert bereits eine funktion namens test() hast in irgend einer include file welche dann ausgeführt wird anstatt der welche du testen möchtest

ka wie ein c compiler bei sowas reagiert aber das würde erklären wieso es anderso geht

eine andere möglichkeit wäre, du sagst du hast die funktionen in einer .c file drin und verwendest sie in einer anderen .c file
ka was der standard und so ist bei c aber der normalfall ist dass du die deklarationen in einer .h file hast und die definitionen in einer .c file, wenn du dann diese funktionen in 2 verschiedenen c files verwenden moechtest dann inkludierst du die .h file in beiden

wenn ka was genau du gemacht hast, #include "deinefile.c" .. ka ob sowas überhaupt geht? möglich dass du denkst du verwendest diese funktionen aber in wirklichkeit sind sie dem compiler nicht bekannt und er macht sie einfach deswegen und sie sind entsprechend leer bzw geben 0 zurück

Zitat von Vevusio

möglich dass du denkst du verwendest diese funktionen aber in wirklichkeit sind sie dem compiler nicht bekannt und er macht sie einfach deswegen und sie sind entsprechend leer bzw geben 0 zurück

Nein. In C89, und das ist der noch immer am weitesten verbreitete Standard, ist es absolut legitim, nicht deklarierte Funktionen aufzurufen. Wenn man sie aber nirgends definiert hat, schreit der Linker. Eine Defaultimplementierung wird dir kein C-Compiler synthetisieren.

und obs jetzt in einem .h(pp) file oder .c(pp) drin steht ist dem compiler herzlich wurscht. Dor wo das include steht wird "mehr oder weniger" eine Art copy-paste gemacht.

mfg Schakal

Zitat von lowkey

int test()

Du solltest dir uebrigens moeglichst frueh, also genau jetzt, angewoehnen, Argumentlisten in C nicht leerzulassen. Eine leere Argumentliste heisst naemlich nicht "diese Funktion hat keine Argumente", sondern aus traditionellen Gruenden leider "diese Funktion koennte Argumente haben, vielleicht auch nicht, aber ich sage es dir nicht". Wenn du ausdruecken willst, dass test keine Argumente nimmt, schreib "void" in die Argumentliste:

int test(void)

Dann kann dein C-Compiler das Programm besser auf Typfehler ueberpruefen.

Danke Kuh, hab das grad bei meinem aktuellen Projekt ergaenzt (wusste es naemlich nicht diese () != (void) und hab natuerlich justament einen Fall gehabt wo im Header () stand und im src dann (blabla)

Bist ja eine ziemliche C-Crack-Kuh!

Zitat von davewood

Bist ja [Plantschkuh!] eine ziemliche C-Crack-Kuh!

ich denk mir auch immer wieder er/sie hat zum fruehstueck nicht gras sondern den C-standard gefressen

Zitat

warum hat im obigen code stack_size nacher den Wert 4?
STACK_GROW_INTERVAL hat den Wert 16.

vl irre ich mich ja total, aber du erzeugst ja einen Float Pointer mit 4*16 Bytes Größe.

sizeof(number) liefert 4 weil die größe vom Pointer geliefert wird
sizeof(*number) liefert das gewünschte ergebnis

sorry falls ich da falsch liege - die pointer zeit is lange her *gg*

sizeof liefert immer nur Konstanten, in deinem zweiten Fall (sizeof(*number)) also sizeof(float) (sofern numbers ein float* ist). Man kann in C einfach nicht die Größe eines mit malloc allozierten Blocks herausfinden.

Zitat von jimbeam

vl irre ich mich ja total, aber du erzeugst ja einen Float Pointer mit 4*16 Bytes Größe.

sizeof(number) liefert 4 weil die größe vom Pointer geliefert wird
sizeof(*number) liefert das gewünschte ergebnis

sorry falls ich da falsch liege - die pointer zeit is lange her *gg*

"sizeof(*number)" liefert die Größe des Pointers, auf einem "normalen" 32-bit Prozessor also 4. Das korrekte Ergebnis würde bei obigem Beispiel "STACK_GROW_INTERVAL * sizeof(float)" liefern. Die Größe von Arrays fixer Größe lässt sich zwar mit sizeof berechnen -- allerdings zieht das insgesamt mehr Verwirrung nach sich als es des Lesbarkeit hilft.

da hattest du schlicht glueck, dass der beriche frei war. wenn du in einen bereich schreibst in dem du nichts verloren hast (der nicht allokiert wurde), dann kann dir das programm auch segfaulten, weil die memory protection vom OS zuschlaegt.

Zitat von davewood

Bist ja eine ziemliche C-Crack-Kuh!

Zitat von Kampi

ich denk mir auch immer wieder er/sie hat zum fruehstueck nicht gras sondern den C-standard gefressen

Muh! Danke für [strike]die Blumen[/strike] den Klee. Vor erschreckend langer Zeit war ich regelmäßiger Gast in comp.lang.c, da lernt man Sachen, von denen einem die Hörner schlackern.

Zitat von lowkey

Ich hatte eine float variable und wollte sie mit folgendem code ausgeben:

Code

printf("The magic number is: %d\n", u);

Ein richtig guter Compiler sollte dich warnen, wenn du sowas probierst. GCC zum Beispiel:

gergo@anneliese:~$ cat falsch.c 
#include <stdio.h>


int main(void)
{
    float u = 3.14159;
    printf("pi ist nicht gleich %d\n", u);
    return 0;
}
gergo@anneliese:~$ gcc -Wall falsch.c 
falsch.c: In function ‘main’:
falsch.c:6: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘double’

Es ist dringendst empfohlen, deinen Compiler (fast... :)) so streng wie möglich zu stellen. Warnings sind nicht dafür da, dir zu zeigen, daß dein Compiler nicht mag, sondern um dir Hilfestellungen zu geben, wie du dein Programm verbessern kannst. Es lohnt sich rauszufinden, wie du deinen Compiler dazu bringst, dir für solchen Code eine Warnung auszugeben.

-Wall -Wextra -ansi -pedantic -O2 rulez.

Zitat von Plantschkuh!

Es ist dringendst empfohlen, deinen Compiler (fast... :)) so streng wie möglich zu stellen. Warnings sind nicht dafür da, dir zu zeigen, daß dein Compiler nicht mag, sondern um dir Hilfestellungen zu geben, wie du dein Programm verbessern kannst. Es lohnt sich rauszufinden, wie du deinen Compiler dazu bringst, dir für solchen Code eine Warnung auszugeben.

-Wall -Wextra -ansi -pedantic -O2 rulez.

Das blöde ist halt, dass sich einige Libraries nicht an diese Empfehlung halten. Dadurch hat man dann halt, wenn man so eine Include-File einbindet, gleich ein paar Screens voll Warnungen, gegen die man eigentlich nichts machen kann.

jaja das gute alte c.
würd ich aber eher nicht für windows anwendungen verwenden.. wenn du natürlich Microcontroller programmierst kanns ganz nett sein;)

Zitat von ThomasW

Das blöde ist halt, dass sich einige Libraries nicht an diese Empfehlung halten. Dadurch hat man dann halt, wenn man so eine Include-File einbindet, gleich ein paar Screens voll Warnungen, gegen die man eigentlich nichts machen kann.

hm, man sollte halt libs von leuten meiden, die keine ahnung vom programmieren haben. bevor mein code nicht bei "-ansi -Wall -pedantic" ohne fehlermeldungen durchlaeuft zeige ich ihn nicht her. ich weisz, das liefert noch lange keine aussage ob es guter code ist, aber es ist imo eine grundvoraussetzung.