C-Standardbibliothek; C89 vs C99

[hallo (aus dem IRC)]

Hallo,

wollte mal die PrettyOs-Stdlib ansprechen.
Einige Sachen sind noch nicht so toll gelöst, wie bsp. strlen.

// Lösung der PrettyOs-Stdlib
// Source: /Source/user/stdlibc/string.c , line 94 - 100
size_t strlen(const char* str)
{
    size_t retval = 0;
    for (; *str != '\0'; ++str)
        ++retval;
    return retval;
}

// ich würde das ganze so lösen:
size_t strlen(const char *str) {
    size_t retval=0;
    while(*(str++)) retval++;
    return retval;
}

Desweiteren fällt mir auf, dass ihr nirgends NULL definiert habt.
NULL ist als symbolische Konstante auf einen Nullzeiger definiert, müsste also so aussehen:

// muss in stdio.h und in stdlib.h
#ifndef NULL
    #define NULL ((void *)0)
#endif // NULL

[Mr X]

Mal abgesehen davon, dass das im Styleguide-Thread deplatziert ist...

Desweiteren fällt mir auf, dass ihr nirgends NULL definiert habt.

Das stimmt nicht. stddef.h definiert NULL im Userspace. Der Kernel enthält keine vollständige C-Standardbibliothek, wir haben uns darauf verständigt, 0 statt NULL zu nutzen. Dennoch ist es, wegen CDI, mittlerweile auch im Kernel definiert.
Beide Definitionen sind aber nicht korrekt:
Für C++ muss NULL als 0 definiert werden. Und der Kernel (nur C) sollte es als (void*)0 definieren, nicht 0. Das werde ich mal beheben.
EDIT: Nein, auch das scheint Unsinn zu sein. Der C99-Standard sagt: "The macros are NULL which expands to an implementation-defined null pointer constant, [...]". Und 0 ist m.E. eine Null-Pointer-Konstante.
EDIT2: Beleg (C99-Standard): "An integer constant expression with the value 0, or such an expression cast to type void *,iscalled a null pointer constant ."

Einige Sachen sind noch nicht so toll gelöst, wie bsp. strlen.

Ich sehe nicht, was an deiner Implementation besser ist. Es ist wohl eine Frage des persönlichen Geschmacks - und ich finde die for()-Implementation verständlicher.

[halllo]

leute! das, was ihr da implementiert, ist eine c standardbibliothek, nicht c++.

c99 wird von wenigen compilern vollständig unterstützt, das spricht nicht für c99.

was wollt ihr nur alle mit eurem c99?

[Jonas OSDever]

Der Kernel ist fuer Clang/GCC gebaut. Und beide unterstuetzen C99.
Desweiteren weiss ich nicht, ob sich der C89-Standard hier unterscheidet

[Mr X]

Der Kernel ist C99. Mit einem C89-Compiler wird er sich nicht kompilieren lassen.

[C89 != C99 !!!!!]

Jonas OSDever schrieb:

Der Kernel ist fuer Clang/GCC gebaut. Und beide unterstuetzen C99.
Desweiteren weiss ich nicht, ob sich der C89-Standard hier unterscheidet

1. 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.

[Mr X]

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.

[Jonas OSDever]

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.

[Jonas OSDever]

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

[is klar]

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

[Jonas OSDever]

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.

[Mr X]

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.

[warum nicht '-c666'?]

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?

[Jonas OSDever]

Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.

[stdlibC]

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.

[c89 rulez]

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.

[MFK]

Gut, dass die Unregs hier jetzt mitdiskutieren können.

*popcornhol*

[Jonas OSDever]

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

[Mr X]

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!