Add VSIFErrorL() and VSIFClearErrL(), robustness fixes in VSICopyFile() #9937
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rouault
force-pushed
the
vsiferrorl
branch
9 times, most recently
from
e39b6d4
to
d385d28
Compare
``` * \fn VSIVirtualHandle::Error() * \brief Test the error indicator. * * Returns TRUE (non-zero) if an error condition occurred during the * previous read operation. The error indicator is cleared by a call to * VSIFClearErrL(). Note that a end-of-file situation, reported by VSIFEofL(), * is *not* an error reported by VSIFErrorL(). ``` ``` * \fn VSIVirtualHandle::ClearErr() * \brief Reset the error and end-of-file indicators. ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Those rationale for this big set of changes is a robustnes fix in VSICopyFile() to detect an error when reading the source file. But it turns out that we have no clean way in the API to distinguish from end-of-file vs error when Read() returns less bytes than requested. Well, we could use Eof() not return true to potentially mean that an error occured, but a number of file systems (e.g /vsigzip/) actually set the Eof flag when an error occured. So to be in known territory, let's fully implement POSIX FILE* API, by adding a Error() and ClearErr() methods that map to POSIX ferror() and clearerr(), and fix implementations where needed. This is a somewhat risky change, and not easy to fully test. MIGRATION_GUIDE.TXT is updated to hint that testing for VSIFEofL() is no longer sufficient to exit a reading loop.