Lines Matching refs:to

7 for changes related to native code loading in various Android releases.
13 You can see the current status with respect to POSIX in the form of tests:
38   * Thread cancellation (`pthread_cancel`). Unlikely to ever be implemented
74   * Bug fixes to handling of UTF-8 U+fffe/U+ffff and code points above U+10ffff.
78     corresponding pointer argument, leading to obscure errors. The scanf family
97 …* <signal.h> support for `sigaction64_t` and `sigset64_t` allowing LP32 access to real-time signals
108   * Passing a null `FILE*` or `DIR*` to libc is now detected at runtime and
135   * Passing an invalid `pthread_t` to libc is now detected at runtime and
272 but there are likely to be more in future because of Project Treble.
276 As part of a long-term goal to remove the global thread list,
277 and in an attempt to flush out racy code, we changed how an invalid
282 message "attempt to use invalid pthread\_t".
287 in the caller, given that callers actually need the tid to pass to some
291 We can't check a thread's tid against 0 to see whether a `pthread_t`
298     should be fine. Unsafe calls to those seem highly unlikely.
300   * Unsafe `pthread_detach` callers probably want to switch to
307     unjoinable thread, the fix is to stop marking it detached. If you're
308     joining an already-joined thread, you need to rethink your design!
311     inherently non-portable as-is.) The best alternative on Android is to
312     use `pthread_gettid_np` at some point that you know the thread to be
330 The `_FORTIFY_SOURCE` macro can be used to enable extra
335 Note that in recent releases Android's FORTIFY has been extended to
337 to open(2) without specifying a mode. It also performs some checking
349 need to manually enable FORTIFY by setting that themselves in whatever
350 build system they're using. The exact subset of FORTIFY available to
352 check can't be guaranteed at compile-time, a call to a run-time `_chk`