Lines Matching refs:it

1 *This document was originally written for a broad audience, and it was*
2 *determined that it'd be good to hold in Bionic's docs, too. Due to the*
3 *ever-changing nature of code, it tries to link to a stable tag of*
35 increasingly strict versions of it. In general, FORTIFY doesn't require user
38 because FORTIFY has significant flexibility in what it considers to be an
135 FORTIFY'ed function from Bionic. From the user's perspective, it supports a few
151 is Android-specific (and orthogonal to FORTIFY anyway), so it will be ignored.
194 So let's walk through this step by step, to see how FORTIFY does what it says on
207 First, it's critical to notice that `mempcpy` is marked `overloadable`. This
219 is generally needed by FORTIFY, but it carries the side-effect that functions
262 - Evaluate it as a constant.
266 - Declare that the expression cannot form a constant, and lower it to
296 it introduces a tiny additional run-time cost to ensure that functions aren't
333 - If `__builtin_object_size(dst, 0)` cannot be determined (in which case, it
350 lowers it to LLVM's `@llvm.objectsize` intrinsic. The `@llvm.objectsize`
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
370 Due to its implementation, it may impact the optimizations that occur on code
375 might make it only-mostly-free to use."
395 In the above breakdown, it was shown how Clang and Bionic work together to:
460 `__builtin_open`, since it's recognized right here. :)
553   parameters of type `T*` --  makes it impossible to take the address of a
565 Bionic's `poll` implementation is closest to `mempcpy` above, though it has a
596   attribute. Hence, for direct calls, overload resolution will always prefer it
621 The other line deserves a section. The subtlety of it is almost entirely in the
628 Earlier in this document, it was said that a full description of each
641 `__builtin_object_size(p, N)` to the caller is critical, since it allows Clang
643 It's not a perfect solution, but it allows `N == 1` to be fully accurate in at
670 greatest possible size for each possible value of `p`. Otherwise, it should
695 if it is set, a closest surrounding subobject is considered the object a pointer
743 `pass_object_size`], it evaluates `__builtin_object_size(p, N)` within the
757   // The frontend can't figure this interprocedural objectsize out, so it gets lowered to
786 `pass_object_size(0)` ... it's somewhat split. `pass_object_size(0)` in Bionic's
803 on LLVM's mailing list seeming interested in trying it someday.
810   answer accurately, since it relies on type info only available in the
811   frontend, and it sometimes relies on optimizations only available in the
816 real world. The main thing it fails to mention is the use of [the `diagnose_as_builtin` attribute] …