search

correctcomputation / checkedc-clang

This is the primary development repository for 3C, a tool for automatically converting legacy C code to the Checked C extension of C, which aims to enforce spatial memory safety. This repository is a fork of Checked C's.
14 stars 5 forks source link

Make 3C work sensibly on already preprocessed code #535

Open mattmccutchen-cci opened 3 years ago

mattmccutchen-cci commented 3 years ago

This issue is to make 3C work "sensibly" on already preprocessed code, whatever we determine that means exactly.

The main part of this that I'm aware of is to make PersistentSourceLoc honor preprocessor-inserted line markers in all cases. This would have the following effects (to my knowledge):

  1. 3C would consider program elements unwritable if they were included from an unwritable file.
  2. 3C would correctly match certain program elements that were included from the same file into multiple translation units. (See the "unless it's preprocessed" section of #499 for an example.)

And the main use case I'm aware of is making it easier for us to reduce a test case that contains #include directives: we can preprocess the file and then proceed with reducing the included content (either manually or using a tool like C-Vise). The change to 3C proposed in this issue would lower (though perhaps not fully eliminate) the risk that preprocessing the test case changes the decisions made by 3C so that the test case no longer reproduces the original bug. I don't know whether end users of 3C would also find this useful.

mattmccutchen-cci commented 3 years ago

One potential problem is that if the presumed location contains a relative path, the path should in principle be resolved relative to the working directory of the translation unit to avoid potential name collisions and resulting confusing behavior, but currently it isn't easy to determine the translation unit working directory after ClangTool::buildASTs returns. We could shoot for fixing this by reimplementing ClangTool::buildASTs (which would also help us with #536) and adding code to save the translation unit working directory.

Absent a real fix, we could just let 3C fall back in some way when it gets a relative path, maybe with an error or warning. If the user is manually running the preprocessor on code before passing it to 3C, they should be able to avoid the problem by passing an absolute source file path and absolute -I paths to the preprocessor.

When not running on preprocessed code (so we want to use the physical path), the canonical physical path is usually available from Clang, but in some cases involving macros (#529), it isn't. This variant of the problem can already occur, independent of the change proposed here to always use the presumed location when it differs from the physical location. #532 fixed it for the main source file, but AFAIK it can still occur for files included via relative -I paths. convert_project avoids relative -I paths as a workaround for #515, and that should help with this problem too.

mattmccutchen-cci commented 3 years ago

532 fixed it for the main source file, but AFAIK it can still occur for files included via relative -I paths.

Update: The problem can still occur not only with relative (or otherwise non-canonical) -I paths, but also with non-canonical paths in the #include directive. I have now filed #604 specifically for this problem.

However, when 3C runs on already preprocessed code, it's unclear whether it would make sense for 3C to try to re-canonicalize the presumed file paths by looking at the current filesystem, since the preprocessed file may have been generated from another directory (or another computer). Unless we have a way to force complete canonicalization of presumed file paths during the original preprocessing (which I'm not sure we can do with clang -E), we may be stuck with incorrect behavior in some (hopefully rare) cases.