Re: perror(), die aktuelle glibc und vielleicht nen bug
michael loeffler <miloeffler@gmx.de> 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.
Reply to: