POSIX vs ANSI C
-
Hi,
Es gibt immer wieder Aspekte in der C-Programmierung wo es einfach heißt:
1. Nicht ANSI-C Standard
od.
2. POSIX schreibt diese Konstanten allerdings nicht vorNun meine Frage: Wenn eines dieser 2 Aussagen der Fall ist, was heißt das im Konkreten genau: Heißt es dass es damit nicht garantiert ist, dass jeder Compiler den Code kompilieren kann oder heißt es, dass das fertig kompilierte Programm dann nicht 100% läuft? Auf was können diese zwei Aussagen denn nun in Wirklichkeit 100% negativen Einfluss haben?
Viele Grüße
-
Nicht jedes System ist POSIX-konform, aber jeder C Compiler sollte möglichst standardkonform sein. Mit einem standardkonformen C-Compiler kannst du jedes standardgetreue Programm übersetzen und es macht dann garantiert das was es überall macht. Wenn du zusätzlich auf einem POSIX-System arbeitest, dann sind eben mehr Sachen festgelegt, auf die du dich verlassen kannst. Aber eben nur in POSIX. Wenn du das Programm mit einem standardkonformen C-Compiler für Windows übersetzt und ausführst, dann passiert eben nicht garantiert genau das gleiche wie auf POSIX-konformen Systemen, eventuell funktioniert es sogar gar nicht oder lässt sich nicht übersetzen.
-
Es sei denn es besteht ein Konflikt zwischen POSIX und C Standard.
-
314159265358979 schrieb:
Es sei denn es besteht ein Konflikt zwischen POSIX und C Standard.
Hmm, gibt's das? Ich kenne den C Standard sehr gut und den POSIX Standard zumindest oberflächlich und mir fällt nichts ein. Es erweckt sogar sehr stark den Eindruck, dass genauestens da drauf geachtet wurde, dass es solche Fälle nicht gibt. Google spuckt auch nichts aus. Hast du ein Beispiel?
-
Folgende Situation: Ein paar Leute setzen sich zusammen und entwerfen eine tolle, neue Sprache. Zunächst schreiben sie die nur für sich selbst, weil sie ein gutes Werkzeug für ihr großes Projekt brauchen, aber mit der Zeit sehen das andere Leute, die sich sagen "Mensch, das ist echt gut. Ich will das auch haben." Also nehmen sie die Sprache und schreiben darin tolle, neue Dinge. Mit der Zeit entwickeln sie unabhängig voneinander neue Spracherweiterungen, die sie für ihre eigenen, großen Projekte nützlich finden, und 10 Jahre später hat man einen unübersichtlichen Wildwuchs ähnlicher, aber untereinander inkompatibler Sprachen. Es gibt ein PDP-C, ein K&R-C, ein VMS-C und so weiter (Anbieternamen zufällig gewählt, keine Garantie für Korrektheit), und wenn Code für eines von diesen geschrieben wurde, ist es reine Glückssache, ob es mit einem der anderen auch funktioniert.
In dieser Situation setzen sich die verschiedenen Anbieter zusammen und versuchen, aus den bestehenden Implementationen etwas gemeinsames zu entwickeln, damit zukünftig ein Programmierer Code einfach in C schreiben kann, ohne sich Gedanken darüber zu machen, ob er später auch mit anderen Compilern funktioniert. Und so erhält man nach langen Diskussionen ANSI-C, welches später von der ISO übernommen wird.
Das ist (grob umrissen) wie Standards zustande kommen. Wenn dein Code sich an einen bestimmten Standard hält, wird er dort laufen, wo dieser Standard erfüllt ist.
ANSI-C wird (fast) überall erfüllt, wo es C-Compiler gibt (Ausnahmen im Mikrocontrollerbereich, soweit ich weiß), es ist also in aller Regel unproblematisch, sich darauf zu stützen (zumindest auf C89; C99 wird von MSVC bis heute nur bruchstückhaft unterstützt). POSIX (Portable Operating System Interface for Unix) ist der grundlegende UNIX-Standard. Er umfasst unter anderem eine C-Schnittstelle, die alle UNIX-Systeme unterstützen (sonst wären es keine UNIX-Systeme). Also wird Code, der sich auf POSIX stützt, auf allen UNIX- und UNIX-artigen Systemen (Linux, Solaris, Mac OS X, *BSD...) laufen, nicht aber auf anderen (etwa Windows).
@SeppJ (Re: Konflikte zwischen POSIX und ANSI-C): Die von POSIX verwendeten Bezeichner sind vom C-Standard nicht für die Implementation reserviert. Dass führt zum Beispiel dazu, dass ein POSIX-konformer Compiler
void accept() { }...was nach ANSI-C gültig ist, nicht unbedingt akzeptieren wird. Microsoft stellt sich auf diesen Standpunkt und stellt allen aus POSIX übernommenen Funktionen einen Unterstrich vor; die Vermutung liegt allerdings nahe, dass dieser Argumentation weniger technische Argumente zugrunde liegen als ein mangelndes Interesse an Kompatibilität zwischen Windows und POSIX. Gleichwohl: Gcc hat eine Option -ansi, die unter anderem bewirkt, dass die Standardheader der glibc keine POSIX-Symbole importieren.
-
-
Es gibt von Microsoft für Windows ein POSIX-Subsystem. Das ist Bestandteil der Services for UNIX
Leider nur für die Pro- Versionen und Server.
