Ralf Corsepius
Vor 13 Jahren gab es praktisch keine ANSI Compiler ;)
Borland/Turbo-C gaben damals vor es zu sein, waren es aber nicht wirklich;
Jo, es hat eine Weile gedauert, bis die Compiler nachgezogen sind. Zugegeben, am Anfang waren mir vor allem die Prototypen wichtig, während sich mir die Feinheiten erst sehr viel später erschlossen haben.
Aus dieser Zeit stammt auch die Masse des X11-Codes, der deshalb auch mit ANSI/KNR-Kompatibilitäts-Macros gespickt ist, ebenso wie die gcc __P()-Macros
Jepp, ich weiss (zu X11 unten mehr). Aber für den gcc gilt ja nur noch für die Teile, die in stage1 übersetzt werden, dass sie auch noch mit steinzeitlichen K&R Compilern übersetzbar sein müssen.
Anders schaut es mit derartigen, in KnR syntaktisch korrekten, aber nur maschinenabhängigen Konstrukten aus:
int foo( int*) int foo( a ) short* a; { }
Diese hochgefährliche Konstruktion wird von -W-Flags in gcc nicht detektiert, ist in KnR-C und älterem "möchtegern" ANSI-C-Code aber nicht selten anzutreffen.
Irrtum :) gcc 2.95.3 ohne jegliche Warnoption: int foo (int *); int foo (a) short *a; { return 0; } t.c: In function `foo': t.c:6: argument `a' doesn't match prototype t.c:1: prototype declaration Aber die implizite Aufweitung (default promotion) bzw. deren Fehlen kann einem richtig Kopfschmerzen bereiten, wenn man K&R Code nach ISO C portiert. Ich habe mich mal vor Jahren daran gemacht, den *internen* Code im XFree86 library Teil aufzuräumen (interne header statt extern Deklarationen in diversen .c, ANSI Prototypen in der Form, wie sie X11 verwendet etc.) und es war für mich doch erstaunlich, was so passieren kann, wenn in Gegenwart von Prototypen die Argumente eben genau so weiter gereicht werden, wie der Prototyp angibt. Bevor ich das aber auch nur halb fertig hatte, ereilte mich das Angebot, für SuSE zu arbeiten. Aber bei dieser Arbeit habe ich eine Menge dazu gelernt. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de