does perror() set errno?

dmail · 08-15-2009, 03:52 PM

ref wje_lq edit:
Yes anybody expecting anything other than what is outputted is in the land of UB. If someone was to say it works then the output is what they _think_ it should be, therefore relying on UB.

ebd · 08-17-2009, 12:25 AM

conclusion:
errno is unreliable ater a successfull system or library function call, because errno may well be changed too. so, only check the errno after a failed function call for which it is explicitly stated to be set to indicate an error.
right?

paulsm4 · 08-17-2009, 12:53 AM

Hi -

Correct.

In other words:

Code:

  int ierr = 0;
  if (open ("myfile", MYFLAGS) < 0)
  {
    ierr = errno; // Copy "errno" for subsequent error handling...

This is good advice, regardless if we're talking about Linux (e.g. "errno.h"), Windows (GetLastError() is admittedly much better - but still suffers more or less the same problem "the next global 'error' will overwrite the current one"...) or even stuff like h_errno (DNS calls, etc).

IMHO .. PSM

PS:
Deliberately performing "Undefined Behavior" (like calling "perror()" multiple times, without any bona fide error for perror to inspect) will, by definition, cause "undefined results".

So even though "save your results variable as quickly as you can" is good advice, I wouldn't necessarily agree that this "experiment" taught you anything useful about how either "error" or "perror()" are actually supposed to work...

jlliagre · 08-17-2009, 04:17 AM

Regardless of whether it complies or not with standards (and indeed we are in UB land), the fact "Illegal seek" is returned means that error happened during the perror call and is still to be explained.

dmail · 08-17-2009, 05:42 AM

Quote:

Originally Posted by jlliagre

... the fact "Illegal seek" is returned means that error happened during the perror call and is still to be explained.

I thought it was already explained?
The facts are that calling perror when there has not been an error is an error in itself. The perror function does not define if it does not change the value of errno so it is unspecified and can change the value to anything it wants, which on this distro and this occasion chose "Illegal seek".

wje_lq · 08-17-2009, 05:44 AM

Quote:

Originally Posted by jlliagre

the fact "Illegal seek" is returned means that error happened during the perror call

Yes. But "error" does not mean "problem".

jlliagre · 08-17-2009, 05:54 AM

I'm afraid this isn't an explanation but just dodging the question.
I have no doubt this illegal seek error, even harmless, not breaking any standard and not a problem per se, is real. I'm just still curious to know why and where it happened. That was the OP question and it is still unanswered.

dmail · 08-17-2009, 06:07 AM

This is like banging my head on a brick wall, it has been explained many times now and I will not be posting again in this thread!

Quote:

Originally Posted by jlliagre

I'm afraid this isn't an explanation but just dodging the question.
I have no doubt this illegal seek error, even harmless, not breaking any standard and not a problem per se, is real.

No it is not real.

Quote:

I'm just still curious to know why and where it happened. That was the OP question and it is still unanswered.

No it is not.

Quote:

The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified.

jlliagre · 08-17-2009, 06:29 AM

"undefined" and "unexplained" are different status. Programs behaviors, whether they are specified or not should always be explainable.

I'm curious to understand why you claim the "Illegal seek" didn't happen for real. How would you demonstrate it ?

wje_lq · 08-17-2009, 11:52 PM

Quote:

Originally Posted by jlliagre

I'm just still curious to know why and where it happened.

Fair enough.

I'm guessing that the seek is real.

perror() gets this setting of errno from its call to fdopen().

fdopen(), in turn, is a complicated chunk of code which is carefully designed to be standards-compliant without breaking any ancient C code. You'll find some seeking done in there. My guess is that under certain conditions, it gets an illegal seek, determines that the error indication is not a problem, and keeps on truckin'.

The one thing that neither perror() nor fdopen() is allowed to do is to set errno to zero. Saving and restoring an old errno would violate this, because that might mean restoring the value zero.

If you wish to explore the source code for fdopen(), be my guest. :)