Re: lib/45587 (rewind(3) errno lossage)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/45587; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/45587 (rewind(3) errno lossage)
Date: Sun, 25 Oct 2020 21:15:03 +0700

     Date:        Sun, 25 Oct 2020 02:03:12 +0000 (UTC)
     From:        dholland%NetBSD.org@localhost
     Message-ID:  <20201025020312.7FF741A923A%mollari.NetBSD.org@localhost>
 
 The PR says:
 
     so I guess clearing and testing errno is the only
     possible way to check for error... but maybe it shouldn't
     be supported anyway. It's certainly not required by C99,
     although I haven't checked POSIX.
 
 What POSIX says on this is...
 
     Since rewind( ) does not return a value, an application
     wishing to detect errors should clear errno, then call
     rewind( ), and if errno is non-zero, assume an error has
     occurred.
 
 That paragraph ix "CX shaded" which means:
 
    CX	Extension to the ISO C standard
 
         The functionality described is an extension to
         the ISO C standard. Application developers may
         make use of an extension as it is supported on
         all POSIX.1-2017-conforming systems.
 
 Back to the PR which also says:
 
 	If this is going to be a supported method of
 	checking whether rewind failed, it should save
 	errno on entry and restore it except on
 	explicit failure.
 
 but I don't think that is correct.
 
 Note that all POSIX says is "assume an error has occurred",
 which unless some completely arbitrary event is happening
 which looks unlikely, would mean any errors that occur while
 rewind() is running.   Errors occurring do not necessarily
 always mean that the function failed.
 
 Errors from the fseek() call are defined to be errors from
 rewind(), all of them, except EINVAL which simply can't
 happen (as defined by POSIX anyway) - that leaves errors
 that occur during the file locking/unlocking, and I'd have
 thought that if one of those generates an error, then that's
 also an error from rewind() (something went terribly wrong
 in that case).   All that leaves, that I can think of, is if
 a signal handler for a caught signal occurs while waiting for
 the lock to be available (some other thread had fp() locked,
 and this one needs to wait for that one to finish).   If
 that signal handler is corrupting errno then the program is
 simply broken - that could cause far worse problems than
 an apparent failure from rewind().
 
 In short, unless there is an actual problem here, something
 is actually failing, more than "man page / code / standards
 reading." making it appear that there might be a problem,
 I don't believe that there is anything here that needs to
 be changed, and certainly a simple "save/restore errno as above"
 would not be correct.
 
 kre
 
 ps: while POSIX does say that the error flag for the FILE *
 gets cleared by rewind(), it doesn't say whether that is
 intended to happen before or after the fseek() call (or
 code to do the equivalent - in our case, it is an fseek()
 call).   Unless the C standard says which order (in which
 case that would apply in POSIX as well, even without the
 POSIX text being explicit on the issue) then there looks to
 be a POSIX defect here - maybe a C standard defect as well.
 This makes no practical difference, as while it would be
 appealing to first clear the error flag, and then call
 fseek() - meaning that the error flag might get set again
 if the fseek() fails, that is clearly not what any implementations
 have ever done, so if the stanrard(s?) ever got updated to
 specify this, it would be to specify that the error flag is
 cleared after the fseek() happens, not before.