[PATCH] Make the presence of stdin and stdout optional
Jonathan Roelofs
jonathan at codesourcery.com
Mon Mar 16 09:12:16 PDT 2015
================
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__)
----------------
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?
================
Comment at: test/std/input.output/iostream.objects/wide.stream.objects/wcout.pass.cpp:18
@@ -17,3 +19,3 @@
{
#if 0
std::wcout << L"Hello World!\n";
----------------
EricWF wrote:
> There is something fishy about this test already.
Indeed... this part is begging to be an ShTest test.
http://reviews.llvm.org/D8340
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
More information about the cfe-commits
mailing list