Skip to content

Extend bounds inference to handle relative alignment. #328

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dtarditi opened this issue Jun 20, 2017 · 0 comments
Open

Extend bounds inference to handle relative alignment. #328

dtarditi opened this issue Jun 20, 2017 · 0 comments
Labels
work item This labels issues that are not exactly bugs but are about improvements.

Comments

@dtarditi
Copy link
Member

We need to make sure that bounds inference properly handles bounds with relative alignment. In addition, we need to introduce relative alignment requirements at casts of array_ptrs.

Normally we can omit relative alignment in a bounds declaration for some array_ptr. It is assumed to be T. So first we face the question of whether to always make relative alignment explicit during bounds inference.

Second, when a pointer p with some type array_ptr is cast to have type array_ptr, p retains its original relative alignment. If no relative alignment has been specified for p, than its relative alignment is sizeof(T).

@dtarditi dtarditi added the work item This labels issues that are not exactly bugs but are about improvements. label Jun 20, 2017
dopelsunce pushed a commit to dopelsunce/checkedc-clang that referenced this issue Sep 28, 2020
An error message for integer members with bounds used the term "variable" where the term "member" should be used..
sulekhark pushed a commit that referenced this issue Feb 27, 2021
…nge. (#391)

This PR addresses function and variable declarations (because they are
the most obvious case and reasonably straightforward) and checked
regions (because they came up in some existing regression tests). We'll
leave #387 open for the tail of unhandled cases.

Also:

- When 3C tries to change a non-writable file, issue an error diagnostic
  (not an assertion failure because there are known unhandled cases)
  rather than silently discarding the change.

- Add a `-dump-unwritable-changes` flag to the `3c` tool to dump the new
  version of the file when that diagnostic appears.

- Add an error diagnostic when 3C tries to change a file under the base
  dir other than the main file in stdout mode. This is a separate
  feature (part of #328) but ended up being easy to implement along with
  the diagnostic for a non-writable file.

- Add tests for all the fixes (but not `-dump-unwritable-changes`).

- Fix a bug where `-warn-all-root-cause` didn't work without
  `-warn-root-cause`, because this affected one of the new tests. The
  use of `-warn-all-root-cause` without `-warn-root-cause` in the
  affected test will serve as a regression test for this fix as well.

Fixes part of #387 and a few unrelated minor issues.
sulekhark pushed a commit that referenced this issue Feb 27, 2021
- Add -output-dir option to write updated files to a directory structure
  parallel to the base dir (#347). When -output-dir is used, a source
  file outside the base dir can't be handled because there is no way to
  compute its output path. For consistency, this is now an error even
  when -output-dir is not used.

- Convert all 3C regression tests from -output-postfix to -output-dir to
  avoid leaving temporary files in the clang/test/3C directory (#378).

- Expand "3c -help" documentation. In particular, direct the user to pass
  "--" when they don't want to use a compilation database to avoid
  accidentally using unwanted compiler options and suppress the warning
  if no compilation database is found (#343).

- For consistency, have stdout mode output the main file even if it is
  unchanged (#328).

- Fix bugs in matching of file paths against the base dir (#327).

- Other minor bug fixes: see the pull request description for details.

Co-authored-by: John Kastner <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
work item This labels issues that are not exactly bugs but are about improvements.
Projects
None yet
Development

No branches or pull requests

1 participant