michael loeffler <[EMAIL PROTECTED]> writes: [perror() ändert errno]
> Zum Thema undefinierter zustand von errno, entweder eine funktion ändert > nichts an errno und führt auch keine anderen funktionen aus die etwas > ändern könnten, oder sie ädert errno bzw. führt weitere funktionen aus > welche dies tun. Das ist wohl wahr: Eine Funktion ändert errno - oder auch nicht. > Undefiniert ist der Zustand nur solange es in keinem > standard oder einer manpage genau beschrieben ist, was es mit errno > anstellt. Ein Blick in die Manpage von errno beschreibt genau das: | [man errno:] | Its value is significant only when the call | returned an error (usually -1), and a library function that does succeed is | allowed to change errno. Da steht es explizit, und in einer Manpage, so wie Du forderst: errno ist nicht aussagekräftig, wenn kein Fehler zurückgemeldet wird. Und in der Manpage von perror() stehts nochmal drin: | [man perror:] | Note that | errno is undefined after a successful library call: this call may well change | this variable, even though it succeeds [...] Was veranlasst Dich zur Annahme, ausgerechnet perror() sei eine Ausnahme von einem Verhalten, das in der Manpage von perror() beschrieben ist? Solltest Du annehmen, dass eine Funktion errno zu setzen hat, obwohl sie keinen Fehler zurückmelden kann und obwohl von errno nichts in der Manpage erwähnt wird, wirst Du nicht bloss bei perror() auf die Schnauze fallen, sondern bei den meisten Systemfunktionen, die void zurückliefern. Also lass' gut sein. -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)