MSan won't currently help us on Android (and I don't think there's a plan to support that any time soon, but eugenis would know better).

I think for Android we'd rather have the debuggability, but +enh for a second opinion.

For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver.

@EricWF ping

@EricWF Any concerns, or can I merge this?

Only opt-in for bionic

I'm not really sure who speaks for glibc platforms. @EricWF? Like I said, if we're not comfortable making this change for glibc I don't have a problem backing that out, but I do think this is a more useful default behavior. It's fairly convoluted to pass a file descriptor from an fstream across an exec boundary intentionally so I somewhat doubt anyone is doing so intentionally. Anyone doing so unintentionally is just leaking an fd and any use of it on the other side of the exec is probably a bug.

Add a comment explaining _LIBCPP_FOPEN_CLOEXEC_MODE.

Ping?

Android maintains its own build scripts, so this won't harm us, but I think the problem in general remains. Seems like it would be better for the webasm target to opt out of the behavior than for all targets to do it (or maybe just provide an option so maintainers can choose what they want for their platform).

In D59839#1444061, @mclow.lists wrote:

I'm mostly worried about the change in behavior breaking existing programs.

In D59839#1443731, @mclow.lists wrote:

How did you decide which modes fell into "when possible"?

Updated to address some review comments:

In D58153#1395601, @efriedma wrote:

The official documentation still says "Your app must perform runtime detection to confirm that NEON-capable machine code can be run on the target device" (https://developer.android.com/ndk/guides/cpu-arm-neon#runtime_detection). Is that wrong?

Added reference to spec in comment.

r346051

Thanks, hadn't found that file. Much cleaner.

LGTM