[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: perror(), die aktuelle glibc und vielleicht nen bug



moin,

* Reinhard Foerster <rf11@inf.tu-dresden.de> [020929 00:31]:
...
> Der call perror("A") ist erfolgreich und hinterläßt damit einen
> undefinierten errno. Das folgende perror("B") ist somit sinnfrei. 
der zweite perror ist nicht sinnfrei, der zeigt an was in errno nun steht,
ne 29 vom ersten perror, das irgend was getrieben hat, daß nen Illegal
Seek verursachte, was auch immer das war.

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. Undefiniert ist der Zustand nur solange es in keinem
standard oder einer manpage genau beschrieben ist, was es mit errno
anstellt.

Bisher war das verhalten von perror allerdings recht konstant, es hat nur
das eine gemacht, nen passenden string zur errno auszuspucken und
gegebenenfalls nen string + doppelpunkt davor zu setzen, es hat dabei aber
kein Illegal Seek verursacht.

> Also errno speichern wie die man-page sagt.
das wär natürlich die lösung für das problem, aber was die manpage sagt
ist sehr allgemein und bezieht sich nicht speziell auf perror (welches
void ist, somit keine fehler zurück gibt aber schon bei der ausgabe des
strings fehler verursachen könnte, welche errno ändern dürften), nur wie
gesagt, die manpage zu perror sagt im zitierten teil nichts direkt zu
perror aus.

Was mich vielmehr interessierte, ist diese Verhaltensänderung von perror.
Es treibt irgendwas wirres, daß den Illegal Seek verursacht. Kommt mir
verdächtig vor.

Es macht tatsächlich nen seek auf die konsole was ESPIPE erzeugt.

dup(2)                                  = 3
fcntl64(3, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0600, st_size=1885, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
_llseek(3, 0, [2036], SEEK_CUR)         = 0
write(3, "x: Success\n", 11)            = 11
close(3)                                = 0

(bzw. das seek ist nicht gescheitert, weil fd 2 eben ne datei war, und
kein terminal)

In der alten libc war nicht so nen aufwand betrieben, da zeigt strace nur
nen write auf fd 2, fertig. (ok, wenn das write net klappt, dann ist dort
errno auch was anderes...)

Mit der ursprünglichen Mail hatte ich mir eigentlich keine kopie von
manpages erhofft, viel mehr ob ichs nun als bug sehn soll, denn laut allen
manpages die sich mit dem thema befassen (und keine geht direkt auf diese
eine sache ein) ists nach jedem aufruf einer fremden funktion möglich daß
errno was anderes ist. Aber da perror halt jetzt aufeinmal solche dinger
macht, das irritiert mich schon. Interessieren würd mich z.B. alles so
halbwegs offizielle was sich nen standard nennt und sich zu perror
ausspricht, was es genau zu tun hat und was nicht.

Ich glaub ich hab zu viel Zeit, aber trotzdem neugierig (auch wenn ich
perror im allgemeinen nicht (oder zumindestens arg selten) benutze) ;)


Bis später...

mfg michael

PS: wenns zu offtopic wird, sollt man vielleicht per PM weiter machen,
oder es sein lassen. Ausserdem gehts mir vor allem um das Verständnis,
nicht um eine Problemlösung.

PPS: Joerg Keller, man hängt Mails mit neuen Themen nicht in andere
Threads, und dein Evolution scheint auch irgendwie kaputt zu sein, oder
ist das wirklich deine .signature? ;)

-- 
gpg --keyserver blackhole.pca.dfn.de --recv-key 8F3E77FC

Attachment: pgpfnJOahQZX8.pgp
Description: PGP signature


Reply to: