Hello World ohne ;

So:

1

#include <stdio.h>

2

3

void main() {

4

 if (printf("Hello World")) {

5

 }

6

}

;) printf ist schließlich eine normale Funktion... sie gibt als Wert die 
Anzahl der geschriebenen Zeichen zurück.

Ist aber kein Standardkonformes C-Programm, weil der Return-Typ von 
main() nicht int ist.

Jetzt fehlt das return-Statement.

Es fehlt nicht. Man darf es hier weglassen. Das entspricht dann einem 
return 0. Das ist eine spezielle Ausnahme, die nur für main() gilt.
Ich hab nie verstanden, wozu diese spezielle Ausnahme gut sein soll, 
aber jetzt weiß ich es: Damit man ein C-Programm ohne Semikolon 
schreiben kann ;-)

Rolf Magnus schrieb:
> Es fehlt nicht.

gcc main.c -o main.exe -Wall
main.c: In function `main':
main.c:6: warning: control reaches end of non-void function

Naja dürfen darf man schon, aber ob das sauberes Programmieren ist...

;-)
Den kannte ich nocht nicht.
Hello world ohne Semikolon ... , tse, tse.

Mark Brandis schrieb:

> gcc main.c -o main.exe -Wall
> main.c: In function `main':
> main.c:6: warning: control reaches end of non-void function

Probier's mal mit:

gcc main.c -o main.exe -Wall -std=c99

> Naja dürfen darf man schon, aber ob das sauberes Programmieren ist...

In ISO-C ist exakt definiert, was dann passiert.
Aber du darfst gerne eine Lösung vorstellen, die das return enthält, 
wenn du kannst ;-)

Einen direkten Weg zum Festlegen des Returnwertes habe ich nicht 
gefunden, indirekt geht das aber.

1

#include <stdio.h>

2

3

int main() {

4

  if (printf("Hello world\n")) {

5

  }

6

  if (getchar() == 'A') {

7

    if (printf("")) { //returns 0

8

    }

9

  } else {

10

    if (printf("\r")) { //returns 1

11

    }

12

  }

13

}

Danach echo $? auf der Konsole eingeben.

Naja, wenn der Compiler den Code so erzeugt, daß eine int-Funktion
immer in einem bestimmten Register ihren Wert zurückgibt,
dann steht der Rückgabewert von printf in eben diesem.
Wenn man in main() kein return hat, steht der Wert von printf
da immer noch drin und letztlich liefert main dann den
letzten Rückgabewert von printf.

Portables Programmieren sieht freilich anders aus.

Liest eigentlich keiner, was ich schreibe? In ISO-C ist genauestens 
definiert, was passiert, wenn main() ohne return-Anweisung verlassen 
wird: Es wird 0 zurückgegeben. Egal, was printf für einen Returnwert 
hatte.

PS: Es kann sein, daß man dazu dem gcc mit -std=c99 sagen muß, daß er 
den Code nicht auf Basis einer seit 11 Jahren veralteten Version von C 
übersetzen soll.

Gelesen habe ich es wohl ... :-)

Du magst ja auch Recht haben. In C++ und (das wusste ich bisher
nicht, aber mag gut sein) ISO-C99 ist kein return so gut wie
return 0.

Aber nur zur Sicherheit: In K&R-C und dem doch noch recht gängigen
ANSI-C ist es eben nicht so.

MS Visual C++ z.B. ist i.W. ANSI-C und hat mit ISO-C99 nicht
viel am Hut.

Rolf Magnus schrieb:
> Es kann sein, daß man dazu dem gcc mit -std=c99 sagen muß, daß er
> den Code nicht auf Basis einer seit 11 Jahren veralteten Version von C
> übersetzen soll.

Ja, muss man.  Default ist -std=gnu89.  Dafür gibt's dort aber dann
auch eine Warnung:

foo.c:7: warning: control reaches end of non-void function

Die gibt es mit -std=c99 oder -std=gnu99 nicht.

Peter schrieb:
> Klaus Wachtler schrieb:
>> MS Visual C++ z.B. ist i.W. ANSI-C und hat mit ISO-C99 nicht
>> viel am Hut.
>
> welche Version?
> Ich habe es gerade mit der 2003 getestet und da kommt keine Warnung oder
> ein Fehler.

Du hast was getestet?
Wenn wegen des fehlenden return kein Fehler kommt, heißt das
noch lange nicht, daß VC++ nennenswert C99-konform wäre.
Mein letzter Stand dazu ist VS2005; das ist von C99 meilenweit
entfernt.
Meines Wissens hat sich seither in diesem Punkt nicht viel
getan, ich lasse mich aber auch gern eines besseren belehren.

Jedenfalls ist es so, daß dank VC++ leider nicht C99 als
komplett eingeführt betrachtet werden kann - auch wenn es
anders sein sollte.

Ein Erlebnis der anderen Art war mal ein Programm, das woanders
entstand und eigentlich für ISO-C99 gedacht war.
Wenn ein Compiler dann sowas wie isnan() nicht kennt, meckert
er halt und man mogelt sich drum rum.
Dann verhielt sich das Ding aber recht schrullig.
Mit etwas Suche kam dann raus, daß NAN (lt. C99 ein Wert einer
ungültigen FP-Zahl) im Quelltext verwendet wird, der Compiler
sich nicht dran stört (weil es zufällig in irgendeiner
Headerdatei definiert war, ich glaube xwindows.h o.s.ä.),
nur leider nicht im Sinne einer "not a number" sondern mit
dem Wert 2. Genau: #define NAN 2...
Soviel zum Thema MS und Konformität.

Hmm, das gibt mir irgendwie zu denken. Einerseits hat Microsoft 
jemanden, der im Komitee sitzt und an neuen Versionen der Norm 
mitarbeitet, andererseits haben sie keinerlei Interesse, das dort 
beschlossene dann auch in ihren Compiler zu integrieren, wenn nicht 
irgendwelche Benutzer explizit danach fragen. Was um alles in der Welt 
haben die dann im Komitee verloren?

Rolf Magnus schrieb:
> Was um alles in der Welt
> haben die dann im Komitee verloren?

Bremsen.

Im Ernst: Seit sich MS den Mike Suttner eingekauft hat (ein geachtetes 
Member des C++ Komitees) ist es mit ihrem C++ Compiler stark bergauf 
gegangen. Ich kann nur hoffen, dass es in C auch so sein wird, dass man 
irgendwann wieder auf die Anlassprogrammierung verzichtet und die Dinge 
von Grund auf korrigiert.

MS versucht halt momentan die ganze Welt auf C# und .Net zu ziehen. C 
Programmierung ist unter Windows sowieso eine Qual und den C++ Zug macht 
man nur deswegen noch mit, weil es da draussen genug Rebellen gibt, die 
C#, Managed-C++ oder VB einfach verweigern. Und das kann sich eine Firma 
wie MS dann doch nicht leisten, auf diese Leute zu verzichten. Das 
kleine Grüppchen der Leute, die mit C an Windows rangehen, ist, so denke 
ich, für MS hingegen verschmerzbar.

Hallo,

du vergisst die Leute die Hardware nah programmieren (Treiber & Co.).
Da geht mit .net bekanntlich gar nichts. Das hat nicht mit Verweigerung 
zu tun, sondern mit einer technischen Notwendigkeit und hauptsächlich 
dafür werden die C(++) Compiler weiterhin entwickelt.

Und unterschätze C nicht. Hier an der FH wird ziemlich laut auf C++ 
geschimpft. In C++ programmiert hier kaum mehr jemand. Die GUI-Sachen 
werden in C# oder Java gemacht, die Hardware nahen Dinge in reinem C.