[PATCH] Make the presence of stdin and stdout optional

[Eric Fiselier]

================
Comment at: include/__config:735-741
@@ -734,2 +734,9 @@
 
+// CloudABI is intended for running networked services. Processes do not
+// have standard input and output channels.
+#ifdef __CloudABI__
+#define _LIBCPP_HAS_NO_STDIN
+#define _LIBCPP_HAS_NO_STDOUT
+#endif
+
 #if defined(__ANDROID__) || defined(__CloudABI__)
----------------
jroelofs wrote:
> EricWF wrote:
> > What I like about `_LIBCPP_HAS_NO_MONOTONIC_CLOCK` and `_LIBCPP_HAS_NO_THREADS` is that they must be explicitly defined be the user. We don't automatically provide those configurations by way of the `__config` header. I like this because those flags make libc++ become a non-conforming standard library.
> > 
> > Along the same vein I'm not sure I like `__config` having configuration paths that make libc++ non-conforming. I understand why this is done in the case of `__CloudABI__` and I'm not objecting. I just want to air my uneasiness. 
> > What I like about _LIBCPP_HAS_NO_MONOTONIC_CLOCK and _LIBCPP_HAS_NO_THREADS is that they must be explicitly defined be the user.
> 
> I can see the reasoning behind it, but this is really inconvenient for me. The problem is that it's not reasonable to expect my users to `#define` these things, so locally I added a `<__config_site>` that `#define`s `_LIBCPP_HAS_NO_MONOTONIC_CLOCK` and `_LIBCPP_HAS_NO_THREADS`, which is `#include`d at the top of `<__config>`.
> 
> I didn't realize this before, but I think the best way forward here would be to have cmake generate the `<__config_site>`, and stick it in an `include` dir in the build directory. Then at install time, have it copy that file to the install dir. This would have the added benefit of making the `-D_LIBCPP_HAS_NO_THREADS=1` things in `config.py` go away. 
> 
> How does that sound, @ericwf?
I like the idea of that but I'm not sure it helps fix this problem per se since it still allows for implicit non-conforming configurations (although I greatly sympathize with the rational for it) I would want to run it by @mclow.lists first. I've thought about this before and my main concern is that it would make reproducing bugs a lot more difficult because every user has a different `<__config_site>` header. 

Perhaps we allow for a `<__config_site>` header to be used, but we only ever provide an empty one with a big comment at the top warning users about modifying it. Then if somebody really needs one of these configurations they can go take the time to manually fill it out with the required definitions. This would make it trickier to use the header in a regular build/test workflow though.

http://reviews.llvm.org/D8340

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/