Szelethus added a comment.

In D78374#2033826 <https://reviews.llvm.org/D78374#2033826>, @balazske wrote:

> I think this is a expected way of how it works, failure of a stream operation 
> does not necessarily depend on result of a previous operation. So any 
> operation can fail or not, independent of the previous error state (the 
> "ferror" may happen because a temporary disk error and it is worth to retry 
> the read, at least a non-`fread` function where the "indeterminate file 
> position" problem does not happen). This would make things more simple. Only 
> the EOF is probably exception, in EOF state any read operation fails with EOF.


Right. But, speaking about generality, would it be reasonably to assume that 
all (or almost all) operations may also result in an indeterminate file 
indicator? Because if so, we could, and totally should strip those changes from 
the fread/fwrite ones and make a new revision.

That is by the way true for a lot of other changes, such as the delayed state 
split or the new error state struct. I mean not to burden you by micromanaging 
a lot of small patches, but it makes reviewing far faster for me.

> (But I do not know if it is possible that a stream in EOF state becomes 
> non-EOF because new data appears at the end, if other program can write into 
> it or it is some form of "pipe" or special file. If this is true even EOF 
> needs no special handling.)

That is a great question, but I strongly believe that it cannot without 
`freopen`. I mean, if I were to create an io library, I would set a pointer to 
the beginning and the end of the file, and know we hit eof is the current 
pointer hits the end point. Besides, how could anyone change the `FILE *` 
object in a non-analyzable way?

In any case, its a reasonable to assume it won't change.



================
Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:937-939
+        new BuiltinBug(this, "Stream is in error state",
+                       "Function called when stream has already error state "
+                       "flag (EOF or error) set."));
----------------
Since this isn't a bug but rather a code smell, a note would be a nice 
compliment.
"Use clearerr() to clear the error flag"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78374/new/

https://reviews.llvm.org/D78374



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to