balazske added a comment.

> No matter what happens during analysis, as of now, the NoteTag message is 
> unambiguous at the point of the tags construction.

The stream error state is designed to store a "superposition" of different 
error states. This is part of `evalFseek`:

  StateFailed = StateFailed->set<StreamMap>(
      StreamSym,
      StreamState::getOpened(Desc, ErrorNone | ErrorFEof | ErrorFError, true));
  C.addTransition(StateFailed,
                  constructNoteTag(C, StreamSym,
                                   {&BT_StreamEof, &BT_IndeterminatePosition}));

The code above means the same as this code:

  StateFailedFEof = StateFailed->set<StreamMap>(
      StreamSym,
      StreamState::getOpened(Desc, ErrorFEof, false));
  C.addTransition(StateFailedFEof, constructNoteTag(C, StreamSym, 
{&BT_StreamEof}));
  
  StateFailedFErrorIndeterminate = StateFailed->set<StreamMap>(
      StreamSym,
      StreamState::getOpened(Desc, ErrorFError, true));
  C.addTransition(StateFailedFErrorIndeterminate, constructNoteTag(C, 
StreamSym, {&BT_IndeterminatePosition}));
  
  StateFailedIndeterminate = StateFailed->set<StreamMap>(
      StreamSym,
      StreamState::getOpened(Desc, ErrorNone, true));
  C.addTransition(StateFailedIndeterminate, constructNoteTag(C, StreamSym, 
{&BT_IndeterminatePosition}));

In this code the NoteTag message is unambiguous. The code above is a 
"compression" of this and at the construction of the NoteTag message is in 
"superposition" state too (like the error state that determines the message).

`freopen` is a different case: At failure it returns a NULL pointer and the 
stream becomes in an invalid state. But if the return value of `freopen` is not 
assigned to it, the stream pointer is not set to NULL:

- `F = freopen(0, "w", F);` F will be NULL at failure, this makes a bug with 
`BT_FileNull` bug type.
- `freopen(0, "w", F);` F becomes invalid but not NULL, if used then a 
`BT_UseAfterOpenFailed` bug is detected (this is the only case for this bug 
type).

At failure of `freopen` we can not tell which case will occur later (it depends 
on the analyzed code). (It may be possible to have only one bug for these cases 
but a differentation is needed to tell the user if a file was NULL or invalid 
but not NULL.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106262

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

Reply via email to