================ @@ -0,0 +1,120 @@ +//===- UnsafeBufferUsage.h --------------------------------------*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#ifndef LLVM_CLANG_ANALYSIS_SCALABLE_ANALYSES_UNSAFEBUFFERUSAGE_H +#define LLVM_CLANG_ANALYSIS_SCALABLE_ANALYSES_UNSAFEBUFFERUSAGE_H + +#include "clang/Analysis/Scalable/Model/EntityId.h" +#include "clang/Analysis/Scalable/Model/SummaryName.h" +#include "clang/Analysis/Scalable/TUSummary/EntitySummary.h" +#include "llvm/ADT/iterator_range.h" +#include <set> + +namespace clang::ssaf { + +/// An EntityPointerLevel represents a level of the declared pointer +/// type of an entity. In the fully-expanded spelling of the declared type, a +/// EntityPointerLevel is associated with a '*' in that declaration. +/// +/// For example, for 'int **p;', there are two EntityPointerLevels. One +/// is associated with 'int **' of 'p' and the other is associated with 'int *' +/// of 'p'. +/// +/// An EntityPointerLevel can be identified by an EntityId and an unsigned +/// integer indicating the pointer level: '(EntityId, PointerLevel)'. A +/// EntityPointerLevel 'P' is valid iff +/// - 'P.EntityId' has a pointer type with at least 'P.PointerLevel' levels +/// (This implies 'P.PointerLevel > 0'); +/// - 'P.EntityId' identifies an lvalue object and 'P.PointerLevel == 0'. +/// The latter case represents address-of expressions. ---------------- jkorous-apple wrote:
That makes me think that this would be an implementation detail of summary extractor. As such, we should not include it in the description of the summary data. (I am making an assumption here that `clang/include/clang/Analysis/Scalable/Analyses/UnsafeBufferUsage/UnsafeBufferUsage.h` defines the summary data.) When I am trying to imagine how we'd use it in the summary extractor I tend to picture that we'll be traversing the AST in the opposite direction. E.g. `&a[5]` -> `&a` -> `a` which would mean that until we won't know the entity until we visit the leaf `DeclRefExpr`. We'd be probably tracking only the pointer level as we traverse the expression, and we can use just `unsigned` for that. https://github.com/llvm/llvm-project/pull/181067 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
