33 FORTIFY is traditionally enabled by passing `-D_FORTIFY_SOURCE=N` to your
34 compiler. `N==0` disables FORTIFY, whereas `N==1`, `N==2`, and `N==3` enable
454 `open("foo", 0, "how do you convert a const char[N] to mode_t?");`. The only
626 ### Subtleties of __builtin_object_size(p, N)
634 `__builtin_object_size(p, N)` and `pass_object_size(N)`, where `(N & 1) == 1`,  argument
636 ignores the value of `N & 1`, since handling `(N & 1) == 1` accurately requires
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
649 `__builtin_object_size(p, N)` is intended to evaluate at compile-time how many  argument
654 assert(__builtin_object_size(buf, N) == 8);
655 assert(__builtin_object_size(buf + 1, N) == 7);
658 This should hold for all values of N that are valid to pass to
659 `__builtin_object_size`. The `N` value of `__builtin_object_size` is a mask of
662 ##### (N & 2) == ?
664 This is mostly for completeness sake; in Bionic's FORTIFY implementation, N is
668 `__builtin_object_size(p, N)`, the second bit in `N` determines the behavior of
669 the compiler. If `(N & 2) == 0`, `__builtin_object_size` should return the
681 ##### (N & 1) == 0
690 ##### (N & 1) == 1, and the true magic of pass_object_size
698 The "closest surrounding subobject," means that `(N & 1) == 1` depends on type
722   // (As a reminder, `-1` is "I don't know" when `(N & 2) == 0`.)
733 C++ data types, so calls to `__builtin_object_size(p, N)` that cannot be
735 `__builtin_object_size(p, N & ~1)` in LLVM IR.
738 accurately determine the answer for `__builtin_object_size(p, N)`, given we know
742 This is where `pass_object_size(N)` comes in. To summarize [the docs for
743 `pass_object_size`], it evaluates `__builtin_object_size(p, N)` within the
746 `__builtin_object_size(parameter, N)` are substituted with references to this
809 - `__builtin_object_size(p, N)` with `(N & 1) == 1` is not easy for Clang to  argument