Bernhard Walle schrieb:
[...] Es kommt auf die Dokumentation an. Wenn dokumentiert ist, dass HZ eine Konstante ist, dann kann man davon ausgehen. Wenn nicht, dann ist es ein Implementierungsdetail auf das man sich nicht verlassen kann genauso wenig wie man sich darauf verlassen kann, dass unter Linux 'char' signed ist, auch wenn es derzeit so ist und wohl auch bleiben wird. Laut Spezifikation von C oder C++ [1] ist darüber nichts ausgesagt. Jeder Code, der davon ausgeht ist zum Scheitern verurteilt.
Du vermischt da IMHO zwei Dinge. Mit dem was Du schreibst, hast Du vollkommen recht: man darf sich als Programmierer nicht darauf ver- lassen, dass gewisse Features, die nicht exakt spezifiziert sind, auf allen Plattformen oder mit allen Compilern, immer und ueberall genau so funktionieren, wie der Programmierer das angedacht hat. Dazu mag eben z.B. die von Dir erwaehnte Problematik mit signed und unsigned gehoeren, aber auch der Speicherbedarf von Variablen unterschiedlicher Typen, usw. Ich kenne etliche C++ Konstrukte, die aeusserst unsauber sind, vom g++ 2.95.x aber ohne Probleme und so- gar ohne Warnung geschluckt werden. Da hat sich mit Version 3.x viel getan. Das alles wuerde ich ganz generell unter dem Punkt "sauberes bzw. unsauberes" Programmieren abhandeln. Etwas anderes ist es, wenn eine Schnittstelle geaendert wird. Wenn eine Bibliothek z.B. eine Funktion bla(int a, int b) hat und nun eine Person daher kommt und das in bla(const int a, const int b) ab- aendert, so ist es nicht verwunderlich, dass es evtl. zu Compilier- problemen kommt. Das hat dann nichts mit der von Dir oben beschrie- benen Spezifikation von C oder C++ zu tun, sondern mit der Spezifi- kation der Schnittstelle. Deswegen wird so oft Wert auf Rueckwaerts- kompatibilitaet gelegt. Ich habe das gerade vor kurzem selbst wieder erlebt: ich hatte eine Mail an den Maintainer der modutils geschickt mit einer in meinen Augen sinnvollen Aenderung. Der Maintainer hat meine Aenderung abgelehnt - aber nicht etwa, weil er sie nicht fuer sinnvoll hielt, sondern weil sie eine Aenderung an einer Stelle her- bei gefuehrt haette, die nach aussen (also fuer den normalen User) sichtbar ist. Jemanden, der sich auf ein gewisses (wenn auch veralte- tes) Feature bzw. Verhalten von modprobe verlassen haette, waere mit meiner Aenderung baden gegangen. Somit muss ich zugeben, dass mein Aenderungsvorschlag zurecht abgelehnt wurde, auch wenn ich ihn nach- wievor fuer sinnvoll halte. So ist eben das Leben mit Software, die rueckwaertskompatibel sein soll. Meine Aenderung waere - uebertrieben gesprochen - bei 99% der User von modprobe sinnvoll gewesen und haet- te bei 1% der User von modprobe zum Versagen gefuehrt; letzteres war eben ausschlaggebend. Was genau im Falle von HZ beim SuSE-Kernel passiert ist, weiss ich nicht. Vielleicht ist es der falsche externe Code, der die Probleme verursacht (wie von Dir beschrieben), oder es ist eine nicht vor- hergesehene Aenderung einer Schnittstelle beim SuSE-Kernel (wie in meiner Mail angedeutet), oder vielleicht auch eine Kombination aus beidem. Ich weiss es nicht. All dem kann man eben auch nur auf den Grund gehen, wenn die Dinge gut dokumentiert sind. Und da hapert es IMHO manchmal, sowohl beim Vanilla-Kernel als auch z.B. bei den SuSE Patches. CU, Th.