clang-tidy android-cloexec-fopen docs should say if e is safe across platforms

[seanm]

The docs for android-cloexec-fopen here:

https://clang.llvm.org/extra/clang-tidy/checks/android/cloexec-fopen.html

say only "fopen() should include e in their mode string; so re would be valid. This is equivalent to having set FD_CLOEXEC on that descriptor."

By having "android" in the check's name, one assumes this works on Android.

The macOS 10.13 through 15.3 man pages say e is supported.

Not sure about Windows, linux, the BSDs, or others.

But most important of all: is it known that adding e would be harmless/ignored on all OSes? If it's not knowm, it's risky to just add an e in cross-platform code, because maybe the e would break some implementations of fopen.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Sean McBride (seanm)

The docs for `android-cloexec-fopen` here:

https://clang.llvm.org/extra/clang-tidy/checks/android/cloexec-fopen.html

say only "fopen() should include e in their mode string; so re would be valid. This is equivalent to having set FD_CLOEXEC on that descriptor."

By having "android" in the check's name, one assumes this works on Android.

The macOS 10.13 through 15.3 man pages say e is supported.

Not sure about Windows, linux, the BSDs, or others.

But most important of all: is it known that adding e would be harmless/ignored on all OSes? If it's not knowm, it's risky to just add an e in cross-platform code, because maybe the e would break some implementations of fopen.