C-Standardbibliothek; C89 vs C99
-
Der Kernel ist C99. Mit einem C89-Compiler wird er sich nicht kompilieren lassen.
-
Jonas OSDever schrieb:
Der Kernel ist fuer Clang/GCC gebaut. Und beide unterstuetzen C99.
Desweiteren weiss ich nicht, ob sich der C89-Standard hier unterscheidet1. http://en.wikipedia.org/wiki/C99#Implementations
von voller unterstützung kann nicht die rede sein.2. http://www.c-plusplus.net/forum/315342
lest euch mal den ganzen thread durch, da gehts am ende auch um c99.
-
Die Diskussion wird mir langsam zu blöd.
Mal ganz davon abgesehen, dass diese beiden Sätze über NULL und "null pointer constant" genauso im C89-Standard stehen.
-
Ein winziger Teil der Standard-Lib fehlt in GCC -> Freestanding environment, nutzen wir eh nicht (oder basteln es uns selber, sollten wir mal irgend so einen seltenen Mist brauchen).
7 C99 Features fehlen oder sind kaputt -> Nur weil wir C99 nutzen heisst das nicht zwangslaeufig, dass wir auch diese 7 Features nutzen.
Das gilt fuer GCC.Bei Clang ist es noch besser, da fehlt nur irgendwas mit Floating points. Ich wuesste nicht, wo wir im Kernel so etwas brauchten.
-
Mr X schrieb:
Die Diskussion wird mir langsam zu blöd.
Mal ganz davon abgesehen, dass diese beiden Sätze über NULL und "null pointer constant" genauso im C89-Standard stehen.
ja, weil du erkennst, dass c99 kein guter weg ist
ich weiße außerdem nochmal darauf hin: c ist nicht c++. ihr implementiert eine c standard-bibliothek, da müsst ihr euch einfach nach c richten. was da c++ vorschreibt, interessiert nicht.
-
Wir implementieren keine C-Standard Bibliothek (zumindest nicht im Kernel, wo das NULL angeblich falsch definiert ist).
Und bei der C-Std-Lib im User-Bereich interessiert uns C++ auch nicht. Da diese Saetze bzgl. NULL genauso in C89 stehen, muss es das auch nicht...EDIT: Da du ja so ein C-Liebhaber bist: Ich persoenlich haette im Kernel sogar Klassen, Namespaces und saemtliches in einem Freestanding Environment erlaubtes C++-Gedoens verwendet, waere ich nicht durch die Projektsprache auf C begrenzt. Vorher hab ich mal einen minimalen Kernel mit Visual C++ (!) implementiert, und der lief auch. Hatte dann nur keinen Bock mich mit Paging rumzuschlagen
-
Jonas OSDever schrieb:
Wir implementieren keine C-Standard Bibliothek (zumindest nicht im Kernel, wo das NULL angeblich falsch definiert ist).
Und bei der C-Std-Lib im User-Bereich interessiert uns C++ auch nicht. Da diese Saetze bzgl. NULL genauso in C89 stehen, muss es das auch nicht...der gcc bringt, wenn man ihn nicht mit der option "-c99" misshandelt, eine fehlermeldung aus, wenn pointern mit integern verglichen werden.
bei aller freundschaft (?) ich glaube, dass compilerhersteller eine bessere standardkenntnis haben als ihr
-
is klar schrieb:
Jonas OSDever schrieb:
Wir implementieren keine C-Standard Bibliothek (zumindest nicht im Kernel, wo das NULL angeblich falsch definiert ist).
Und bei der C-Std-Lib im User-Bereich interessiert uns C++ auch nicht. Da diese Saetze bzgl. NULL genauso in C89 stehen, muss es das auch nicht...der gcc bringt, wenn man ihn nicht mit der option "-c99" misshandelt, eine fehlermeldung aus, wenn pointern mit integern verglichen werden.
bei aller freundschaft (?) ich glaube, dass compilerhersteller eine bessere standardkenntnis haben als ihr
Was uns aber auch nicht zu Interessieren braucht, weil der Kernel mit -C99 kompiliert wird.
-
ja, weil du erkennst, dass c99 kein guter weg ist
C89-Code ist einfach eklig, weil die Sprache fast nichts kann. Der C99-Standard ist auch unschön, weil er sich in mancher Hinsicht von C++ wegbewegt.
ich weiße außerdem nochmal darauf hin: c ist nicht c++. ihr implementiert eine c standard-bibliothek, da müsst ihr euch einfach nach c richten. was da c++ vorschreibt, interessiert nicht.
Du kannst auch noch zehn mal darauf hinweisen - es bleibt falsch.
Die C-Header haben C++-Kompatibilität aufzuweisen, weil wir auch C++-Userprogramme unterstützen. Was C++ ist, wird hinter #ifdef _cplusplus versteckt, was C-spezifisch ist, hinter dem dazugehörenden #else.
Außerdem reden wir die ganze Zeit von C - die Aussagen sind durch den C99-Standard (und gerne auch C89 oder C11 - denn sie stehen unverändert auch in diesen Standards) belegt.
-
Jonas OSDever schrieb:
is klar schrieb:
Jonas OSDever schrieb:
Wir implementieren keine C-Standard Bibliothek (zumindest nicht im Kernel, wo das NULL angeblich falsch definiert ist).
Und bei der C-Std-Lib im User-Bereich interessiert uns C++ auch nicht. Da diese Saetze bzgl. NULL genauso in C89 stehen, muss es das auch nicht...der gcc bringt, wenn man ihn nicht mit der option "-c99" misshandelt, eine fehlermeldung aus, wenn pointern mit integern verglichen werden.
bei aller freundschaft (?) ich glaube, dass compilerhersteller eine bessere standardkenntnis haben als ihr
Was uns aber auch nicht zu Interessieren braucht, weil der Kernel mit -C99 kompiliert wird.
trotzdem. wer pointer mit integern vergleicht, hat schon selbst seinen kenntnisstand verraten.
soetwas gehört einfach zum guten ton in c. pointer werden mit pointern vergleichen, integer werden mit integern verglichen.
oder vergleichst du äpfel und birnen?
-
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
-
Mr X schrieb:
ja, weil du erkennst, dass c99 kein guter weg ist
C89-Code ist einfach eklig, weil die Sprache fast nichts kann. Der C99-Standard ist auch unschön, weil er sich in mancher Hinsicht von C++ wegbewegt.
wer c++ programmieren will, der muss c++ programmieren und nicht c.
wenn du sagst, dass c89 eklig ist, dann sagst du gleichzeitig, dass c eklig ist.
c ist halt so.
der ordner heißt übrigens "stdlibc".
und alle dateien haben die endung .c oder .h.
-
Jonas OSDever schrieb:
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
programmiert ihr nicht unter windows? ich nehme mal an, ihr benutzt den microsoft c++ kompiler, der einen c-modus hat... aber einen c89 modus
der ms-compiler unterstützt garkein c99.
tja, wie es aussieht, habt ihr aufs falsche pferd gesetzt.
außerdem habt ihr anscheinend nicht ganz verstanden, worauf es beim c-programmieren ankommt.
wie der code am ende aussieht, interessiert keinen. meistens gilt: desto kürzer, desto besser.
for schleifen sind hier völlig unnütz.
-
Gut, dass die Unregs hier jetzt mitdiskutieren können.
*popcornhol*
-
c89 rulez schrieb:
Jonas OSDever schrieb:
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
Nope, steht genauso im C89-Standard
c89 rulez schrieb:
wie der code am ende aussieht, interessiert keinen. meistens gilt: desto kürzer, desto besser.
Weil NULL ja auch kuerzer als 0 ist...
MFK schrieb:
*popcornhol*
Spagetti mit Pilzsauce machen sich bei so einer Dis(s)kussion auch vorzueglich
-
programmiert ihr nicht unter windows? ich nehme mal an, ihr benutzt den microsoft c++ kompiler, der einen c-modus hat... aber einen c89 modus
Nein, den benutzen wir nicht (für PrettyOS), weil er für die Erzeugung von ELF- oder rohen Binärdateien einfach schlecht geeignet ist.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
Meine Güte. Jetzt lies erstmal jede einzelne Antwort von mir nochmal, bevor Du wieder was schreibst. Gerne auch zusätzlich noch einen C-Standard deiner Wahl.
der ordner heißt übrigens "stdlibc".
und alle dateien haben die endung .c oder .h.
Wirf ruhig mal einen Blick in übliche Implementationen von C und C++-Standardbibliotheken (z.B. MSVC, die habe ich hier vorliegen). Die C++-Header, die den C-Standard wrappen, machen einfach ein #include <stdio.h> (im Falle von <cstdio>) und verpacken das Ergebnis dann noch ggf. in namespaces. D.h. C++-spezifische Abweichungen von C sind im Header der C-Standardbibliothek enthalten!
-
MFK schrieb:
Gut, dass die Unregs hier jetzt mitdiskutieren können.
*popcornhol*
der umstand, dass ich nicht registriert bin, sagt nichts über die qualität meiner beiträge aus.
Mr X, du sagst, dass C89 ekelig ist. Das ist halt so. Die guten C-Quellcodes sind meistens verschachtelt und schwer lesbar, dadurch zeigt aber der Programmierer, dass er weiß was er tut, und dass er weiß, wie man code gut optimiert.
-
Die guten C-Quellcodes sind meistens verschachtelt und schwer lesbar, dadurch zeigt aber der Programmierer, dass er weiß was er tut, und dass er weiß, wie man code gut optimiert.
Ja sicher... Und das ist auch voll kompatibel mit dem Anspruch von PrettyOS, einsteigerfreundlichen Code zu haben.
-
Jonas OSDever schrieb:
c89 rulez schrieb:
Jonas OSDever schrieb:
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
Nope, steht genauso im C89-Standard
der gcc kompiliert standardmäßig im c89-modus und gibt warnungen.
das reicht mir. wenn ein compilerhersteller, der wahrscheinlich den originalen c-standard gelesen hat, meint, dass ich das so machen soll, dann mach ich das auch so. ich habe übrigens noch kein lehrbuch gesehen, in dem empfohlen wird, pointer mit 0 zu prüfen.c89 rulez schrieb:
wie der code am ende aussieht, interessiert keinen. meistens gilt: desto kürzer, desto besser.
Weil NULL ja auch kuerzer als 0 ist...
du drehst mir die worte im mund herum. du weißt doch hoffentlich, wie das gemeint war, oder? wenn ich einen 100zeiligen code schreibe, den man genausogut in 20 zeilen schreiben könnte, ist die 20 zeilen methode meist die bessere.
wie sagte schon goethe: "Nichts ist schlimmer als eine tätige Unwissenheit."
-
Mr X schrieb:
Die guten C-Quellcodes sind meistens verschachtelt und schwer lesbar, dadurch zeigt aber der Programmierer, dass er weiß was er tut, und dass er weiß, wie man code gut optimiert.
Ja sicher... Und das ist auch voll kompatibel mit dem Anspruch von PrettyOS, einsteigerfreundlichen Code zu haben.
anfänger haben bei der betriebssystem-programmierung nix verloren.
die sollen erstmal richtig c lernen.