Lines Matching refs:be

2 *determined that it'd be good to hold in Bionic's docs, too. Due to the*
15 getting up-to-speed on how things function can be quite difficult.
38 because FORTIFY has significant flexibility in what it considers to be an
60 Textually, quite a bit can be shared between a FORTIFY implementation for GCC
105 make similar promises with respect to FORTIFY compiling to be zero-overhead in
110 **In general, when reading the below, be prepared for exceptions, subtlety, and
116 Because FORTIFY should be mostly transparent to developers, there are inherent
119 `memcpy` call with `_FORTIFY_SOURCE` enabled needs to be able to refer to the
142 - Compiling away to be zero overhead when none of the buffer sizes can be
151 is Android-specific (and orthogonal to FORTIFY anyway), so it will be ignored.
201 `if (...) { ... }` can be optimized out. Depending on how late this happens,
214   given name to not be marked with `__attribute__((overloadable))`. Calls to
215   this overload will not be mangled.
220 may be overloaded simply on the presence (or lack of presence) of
238 Once one is convinced that the FORTIFY-enabled overload of `mempcpy` will be
265     `p` can be known without optimizations.
270 caller, Clang should be able to trivially determine that `buf` refers to a
273 The primary consequence of the above is that diagnostics can only be emitted if
274 no optimizations are required to detect a broken code pattern. To be specific,
275 clang's constexpr evaluator must be able to determine the logical object that
288   mempcpy(buf_ptr, input_buf, 5); // No compile-time error; `buf_ptr`'s target can't be determined.
333 - If `__builtin_object_size(dst, 0)` cannot be determined (in which case, it
335 - Otherwise, if `copy_amount` can be folded to a constant, and if
340 How can this be "zero overhead"? Let's focus on the following part of the
354 Hence, `bos_dst` is guaranteed to be a constant; if it's -1, the above branch
355 can be eliminated entirely, since it folds to `if (false && ...)`. Further, the
363 `__builtin_object_size` and `__builtin_constant_p` are forced to be constants
374 type should be zero cost with any level of optimization enabled, but edge-cases
379 In cases where checking can be performed (e.g., where we call
398 - insert run-time checks for uses of functions that might be incorrect, but only
449 Which may be a lot to take in.
489 `int(const char *, int, mode_t, ...)` for calls where the 3rd arg can be
517 requires mode bits to be set."
601 - If this can't be observed until run-time, `__poll_chk` verifies this.
635 can only be accurately determined by Clang. LLVM's `@llvm.objectsize` intrinsic
643 It's not a perfect solution, but it allows `N == 1` to be fully accurate in at
647 Clang's implementation of `__builtin_object_size` aims to be compatible with
650 bytes can be accessed after `p` in a well-defined way. Straightforward examples
687 the pointer in question. If that can be determined, Clang or LLVM can provide an
733 C++ data types, so calls to `__builtin_object_size(p, N)` that cannot be
815 The above should be a roughly comprehensive view of how FORTIFY works in the
836 [similar to C++11's `std::unique_ptr`]: https://stackoverflow.com/questions/58339165/why-can-a-t-be…