The checker warns if a stream is read that is already in EOF state.
The commit adds indication of locations where the EOF flag is set
on the stream and where it is discovered by the program.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I could not find a way to pass the needed information from the BugReport to the NoteTag. The "sequence number" (in EofSeqMap) is only known when the bug is detected, this should be passed to the NoteTag somehow. The value is used to make the new note appear only at the last place where EOF is set.
Is it better to save the actual ExplodedNode in the note tag? Then the error node of the BugReport can be used to search the bug path and check if the saved node is encountered. In this way a NoteTag could be used and the "sequence numbers" would be unnecessary.
You can capture it.
That's the whole point of note tags, to have access to all the information from both the bug report and the moment of time the event has happened.
+1 for note tags.
clang/test/Analysis/stream-note.c | ||
---|---|---|
134 | Perhaps we could have some more explanatory test case names. I mean how _3 is different than _2? What is the case each of them exactly tests? | |
141 | Strictly speaking it is not necessarily and end-of-file status, ferror indicates if there was an error. |
Updated to use NoteTag.
Note "End-of-file status is discovered here" is removed.
clang/test/Analysis/stream-note.c | ||
---|---|---|
141 | Exacly the ferror(F) is false here. If it is false we may have successful read or EOF after read. So the message about "Assuming that stream reaches end-of-file here" is really an assumption here (pick one from the two possible results). And if EOF happens and ferror is false the feof must be true, this is revealed when we know that ferror is false. |
Let's simplify this even further!
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
419–421 | I guess it's a matter of preference but I really don't understand the need to define a structure when a lambda is sufficient. Lambda is the intended syntax sugar for exactly what you have written. | |
425–426 | You can compare BugType objects directly (by address). | |
429–435 | This code says "If there exists a state below in the path where the stream is not at EOF, drop the note". The report will not be emitted at all if the stream is not at EOF at the end, right? Are you trying to account for the situation when the stream gets reset into a non-EOF state and therefore you don't need to emit the note above that point? In such cases the intended solution is to add another note tag to mark the stream uninteresting once it gets reset, because all the history before that point is irrelevant to our report entirely (whatever the previous position was, its get completely overwritten by the reset). The API for marking objects uninteresting is not yet there but it's suggested in D104300. I believe you should rebase your patch on top of it and take advantage of it as it lands. |
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
419–421 | The reason is that the NoteTag is added at more than one place. And I do not want a function that returns a lambda. | |
429–435 | It was unknown to me if the visit of NoteTag's happens from the bug path end to begin or in different way. If it is from end to begin it may be enough to remove the interestingness in the current NoteTag function when a message is produced, it should find exactly the last place where that EOF flag is set to true. And NotePosition is not needed. | |
429–435 | I tried it out, seems to work. But to continue D104300 should be finished or the "reset of interestingness" must be split to a separate change (or into this patch), is this possible? |
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
429–435 |
Yes, I think it would be the logical way forward if we want a smooth development with this change. So let's create a parent patch that implements solely markNotInteresting from D104300. And that new patch should be the parent of this patch, also D104300 could be rebased once the new patch of markNotInteresting is landed. |
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
419–421 | Problem solved: see constructSetEofNoteTag |
The bug reports speak for themselves, they are awesome. Nice work!
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
28–30 | Thank you! Big fan of these. | |
34–35 | You don't seem to reuse these in this or the followup patch? Its not a big deal, I don't mind you creating them, just feels a bit odd to me. | |
404 | Can you not capture this as well? We could eliminate StreamChecker::Instance that way I suppose. | |
722–728 | Oh, this took me quite a bit. Can we change SS to something that reflects that its the current error state, not the new one? Like CurrSS? |
Looks great now!
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
411 | The word "that" looks redundant, we don't use it in any other similar notes, eg. "Assuming |
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp | ||
---|---|---|
34–35 | These remained from old version of the patch, removed. |
Thank you! Big fan of these.