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)
