|
Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
| #
b9a2658a |
| 21-Dec-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)
This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)
This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the RFC, we initially proposed selecting the right headers from the Clang driver, however consensus seemed to steer towards handling this in the library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public header look like this:
``` // inside <vector> #ifdef _LIBCPP_CXX03_LANG # include <__cxx03/vector> #else // normal <vector> content #endif ```
In most cases, public headers are simple umbrella headers so there isn't much code in the #else branch. In other cases, the #else branch contains the actual implementation of the header.
show more ...
|
|
Revision tags: llvmorg-19.1.6 |
|
| #
c166a9c7 |
| 10-Dec-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Add #if 0 block to all the top-level headers (#119234)
Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a sep
[libc++] Add #if 0 block to all the top-level headers (#119234)
Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead.
This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
show more ...
|
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
| #
d6832a61 |
| 05-Sep-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++][modules] Modularize <cstddef> (#107254)
Many headers include `<cstddef>` just for size_t, and pulling in
additional content (e.g. the traits used for std::byte) is unnecessary.
To solve t
[libc++][modules] Modularize <cstddef> (#107254)
Many headers include `<cstddef>` just for size_t, and pulling in
additional content (e.g. the traits used for std::byte) is unnecessary.
To solve this problem, this patch splits up `<cstddef>` into
subcomponents so that headers can include only the parts that they
actually require.
This has the added benefit of making the modules build a lot stricter
with respect to IWYU, and also providing a canonical location where we
define `std::size_t` and friends (which were previously defined in
multiple headers like `<cstddef>` and `<ctime>`).
After this patch, there's still many places in the codebase where we
include `<cstddef>` when `<__cstddef/size_t.h>` would be sufficient.
This patch focuses on removing `<cstddef>` includes from __type_traits
to make these headers non-circular with `<cstddef>`. Additional
refactorings can be tackled separately.
show more ...
|
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
| #
37dca605 |
| 29-Feb-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Clean up includes of <__assert> (#80091)
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
th
[libc++] Clean up includes of <__assert> (#80091)
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
show more ...
|
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
| #
761b9d9e |
| 10-Jan-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove _LIBCPP_C_HAS_NO_GETS (#77346)
Since we use _LIBCPP_USING_IF_EXISTS to handle missing C library functions
now, _LIBCPP_C_HAS_NO_GETS shouldn't be necessary anymore.
See the discuss
[libc++] Remove _LIBCPP_C_HAS_NO_GETS (#77346)
Since we use _LIBCPP_USING_IF_EXISTS to handle missing C library functions
now, _LIBCPP_C_HAS_NO_GETS shouldn't be necessary anymore.
See the discussion thread in #77242 for more details.
show more ...
|
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5 |
|
| #
e734bc53 |
| 13-Nov-2023 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove _LIBCPP_HAS_NO_FGETPOS_FSETPOS (#72073)
Instead of using individual macros to turn off missing C library
features, we use the using_if_exists attribute now. This patch removes
the
[libc++] Remove _LIBCPP_HAS_NO_FGETPOS_FSETPOS (#72073)
Instead of using individual macros to turn off missing C library
features, we use the using_if_exists attribute now. This patch removes
the _LIBCPP_HAS_NO_FGETPOS_FSETPOS macro used to workaround missing
fgetpos and fsetpos on older versions of Android -- using_if_exists
should take care of those in the headers and we should add appropriate
XFAILs to the tests instead of using TEST_HAS_NO_FGETPOS_FSETPOS.
show more ...
|
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
| #
8cedff10 |
| 08-Aug-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Diagnose when header search paths are set up incorrectly
An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly w
[libc++] Diagnose when header search paths are set up incorrectly
An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add `-isystem <some-toolchain>/usr/include`, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly.
In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors.
Differential Revision: https://reviews.llvm.org/D131441
show more ...
|
|
Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
385cc25a |
| 25-Mar-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Ensure that all public C++ headers include <__assert>
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any publ
[libc++] Ensure that all public C++ headers include <__assert>
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
fa6b9e40 |
| 02-Feb-2022 |
Arthur O'Dwyer <arthur.j.odwyer@gmail.com> |
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D1188
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D118800
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
eb8650a7 |
| 17-Nov-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[runtimes][NFC] Remove filenames at the top of the license notice
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste st
[runtimes][NFC] Remove filenames at the top of the license notice
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
87dd5198 |
| 24-Aug-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove support for CloudABI, which has been abandoned
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI project has been abandoned. This patch removes a bunch of Cl
[libc++] Remove support for CloudABI, which has been abandoned
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI project has been abandoned. This patch removes a bunch of CloudABI specific logic that had been added to support that platform.
Note that some knobs like LIBCXX_ENABLE_STDIN and LIBCXX_ENABLE_STDOUT coud be useful in their own right, however those are currently broken. If we want to re-add such knobs in the future, we can do it like we've done it for localization & friends so that we can officially support that configuration.
Differential Revision: https://reviews.llvm.org/D108637
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
a9c9183c |
| 02-Jun-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Use the using_if_exists attribute when provided
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when the compiler supports it. This makes it easier to port libc++ on to
[libc++] Use the using_if_exists attribute when provided
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when the compiler supports it. This makes it easier to port libc++ on top of new platforms that don't fully support the C Standard library.
Previously, libc++ would fail to build when trying to import a missing declaration in a <cXXXX> header. With the attribute, the declaration will simply not be imported into namespace std, and hence it won't be available for libc++ to use. In many cases, the declarations were *not* actually required for libc++ to work (they were only surfaced for users to use them as std::XXXX), so not importing them into namespace std is acceptable.
The same thing could be achieved by conscious usage of `#ifdef` along with platform detection, however that quickly creates a maintenance problem as libc++ is ported to new platforms. Furthermore, this problem is exacerbated when mixed with vendor internal-only platforms, which can lead to difficulties maintaining a downstream fork of the library.
For the time being, we only use the using_if_exists attribute when it is supported. At some point in the future, we will start removing #ifdef paths that are unnecessary when the attribute is supported, and folks who need those #ifdef paths will be required to use a compiler that supports the attribute.
[1]: http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html
Differential Revision: https://reviews.llvm.org/D90257
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
4cd6ca10 |
| 20-Apr-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] NFC: Normalize `#endif //` comment indentation
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4 |
|
| #
75c44086 |
| 12-Mar-2020 |
Dan Albert <danalbert@google.com> |
Reland: Don't expose unavailable cstdio functions.
Marked unsupported for C++03 and C++11 since this test uses alias declarations, and at least one C++03 bot was failing with -Wc++11-extensions.
Ch
Reland: Don't expose unavailable cstdio functions.
Marked unsupported for C++03 and C++11 since this test uses alias declarations, and at least one C++03 bot was failing with -Wc++11-extensions.
Change-Id: I8c3a579edd7eb83e0bc74e85d116b68f22400161
show more ...
|
| #
50280c18 |
| 07-Apr-2020 |
Dan Albert <danalbert@google.com> |
Revert "Don't expose unavailable cstdio functions."
Broke builders that emit different diagnostics. e.g.:
error: 'warning' diagnostics seen but not expected: Line 13: alias declarations are a C++
Revert "Don't expose unavailable cstdio functions."
Broke builders that emit different diagnostics. e.g.:
error: 'warning' diagnostics seen but not expected: Line 13: alias declarations are a C++11 extension Line 20: alias declarations are a C++11 extension
This reverts commit ff87813715ec32741ce230dd37c13d0ae6673f9c.
show more ...
|
| #
ff878137 |
| 07-Apr-2020 |
Dan Albert <danalbert@google.com> |
Don't expose unavailable cstdio functions.
Summary: These aren't available on Android in all configurations.
Reviewers: EricWF, mclow.lists, #libc, ldionne
Reviewed By: EricWF, #libc, ldionne
Sub
Don't expose unavailable cstdio functions.
Summary: These aren't available on Android in all configurations.
Reviewers: EricWF, mclow.lists, #libc, ldionne
Reviewed By: EricWF, #libc, ldionne
Subscribers: broadwaylamb, dexonsmith, ldionne, krytarowski, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76093
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4 |
|
| #
5bd4a480 |
| 07-Sep-2019 |
Dimitry Andric <dimitry@andric.com> |
Remove ::gets for FreeBSD 13 and later
Summary: In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed gets() from FreeBSD 13's libc, and our copies of libc++ and libstdc++. In that ch
Remove ::gets for FreeBSD 13 and later
Summary: In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed gets() from FreeBSD 13's libc, and our copies of libc++ and libstdc++. In that change, the declarations were simply deleted, but I would like to propose this conditional test instead.
Reviewers: EricWF, mclow.lists, emaste
Reviewed By: mclow.lists
Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits
Differential Revision: https://reviews.llvm.org/D67316
llvm-svn: 371324
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
57b08b09 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions.
We understand that
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351648
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
| #
17af695f |
| 07-Apr-2017 |
Shoaib Meenai <smeenai@fb.com> |
[libc++] Drop support for CRTs older than VS 2015
LLVM dropped support for Visual Studio versions older than 2015 quite some time ago, so I consider it safe to drop libc++'s support for older CRTs.
[libc++] Drop support for CRTs older than VS 2015
LLVM dropped support for Visual Studio versions older than 2015 quite some time ago, so I consider it safe to drop libc++'s support for older CRTs. The CRT in Visual Studio 2015 provides a lot of previously missing functions, so targeting it requires less special casing.
Differential Revision: https://reviews.llvm.org/D31798
llvm-svn: 299743
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
76728d88 |
| 08-Nov-2016 |
Shoaib Meenai <smeenai@fb.com> |
[libc++] Remove unnecessary MSVCRT exclusions
Visual Studio 2013 and up have these functions, and we don't need to support older versions.
There are some remaining _LIBCPP_MSVCRT exclusions which a
[libc++] Remove unnecessary MSVCRT exclusions
Visual Studio 2013 and up have these functions, and we don't need to support older versions.
There are some remaining _LIBCPP_MSVCRT exclusions which are present on Visual Studio 2015 but not 2013. Those will be addressed in a follow-up.
Differential Revision: https://reviews.llvm.org/D26377
llvm-svn: 286202
show more ...
|
| #
e68b4707 |
| 01-Sep-2016 |
Saleem Abdulrasool <compnerd@compnerd.org> |
cstdio: limit gets to CRT versions below 14
Microsoft removed gets from the CRT in Visual Studio 2015 onwards [1]. Attempting to reference it when targeting CRT versions 14 and above will cause comp
cstdio: limit gets to CRT versions below 14
Microsoft removed gets from the CRT in Visual Studio 2015 onwards [1]. Attempting to reference it when targeting CRT versions 14 and above will cause compile errors.
[1] https://msdn.microsoft.com/en-us/library/2029ea5f.aspx
Patch by Shoaib Meenai!
llvm-svn: 280417
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
| #
d3282740 |
| 09-Oct-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Split <stdio.h> out of <cstdio>.
As with <stddef.h>, skip our custom header if __need_FILE or __need___FILE is defined.
llvm-svn: 249798
|
| #
1607bb38 |
| 06-Oct-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Remove unnecessary inline functions capturing the contents of C library macros.
The C standard requires that these be provided as functions even if they're also provided as macros, and a strict read
Remove unnecessary inline functions capturing the contents of C library macros.
The C standard requires that these be provided as functions even if they're also provided as macros, and a strict reading of the C++ standard library rules suggests that (for instance) &::isdigit == &::std::isdigit, so these wrappers are technically non-conforming.
llvm-svn: 249475
show more ...
|
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1 |
|
| #
f4ac884f |
| 26-Mar-2015 |
Ed Schouten <ed@nuxi.nl> |
Make the presence of stdin and stdout optional.
The idea behind Nuxi CloudABI is that it is targeted at (but not limited to) running networked services in a sandboxed environment. The model behind s
Make the presence of stdin and stdout optional.
The idea behind Nuxi CloudABI is that it is targeted at (but not limited to) running networked services in a sandboxed environment. The model behind stdin, stdout and stderr is strongly focused on interactive tools in a command shell. CloudABI does not support the notion of stdin and stdout, as 'standard input/output' does not apply to services. The concept of stderr does makes sense though, as services do need some mechanism to log error messages in a uniform way.
This patch extends libc++ in such a way that std::cin and std::cout and the associated <cstdio>/<cwchar> functions can be disabled through the flags _LIBCPP_HAS_NO_STDIN and _LIBCPP_HAS_NO_STDOUT, respectively. At the same time it attempts to clean up src/iostream.cpp a bit. Instead of using a single array of mbstate_t objects and hardcoding the array indices, it creates separate objects that declared next to the iostream objects and their buffers. The code is also restructured by interleaving the construction and setup of c* and wc* objects. That way it is more obvious that this is done identically.
The c* and wc* objects already have separate unit tests. Make use of this fact by adding XFAILs in case libcpp-has-no-std* is set. That way the tests work in both directions. If stdin or stdout is disabled, these tests will therefore test for the absence of c* and wc*.
Differential Revision: http://reviews.llvm.org/D8340
llvm-svn: 233275
show more ...
|
|
Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1 |
|
| #
97fdea61 |
| 12-Mar-2015 |
Ed Schouten <ed@nuxi.nl> |
Add option to disable access to the global filesystem namespace.
Systems like FreeBSD's Capsicum and Nuxi CloudABI apply the concept of capability-based security on the way processes can interact wi
Add option to disable access to the global filesystem namespace.
Systems like FreeBSD's Capsicum and Nuxi CloudABI apply the concept of capability-based security on the way processes can interact with the filesystem API. It is no longer possible to interact with the VFS through calls like open(), unlink(), rename(), etc. Instead, processes are only allowed to interact with files and directories to which they have been granted access. The *at() functions can be used for this purpose.
This change adds a new config switch called _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE. If set, all functionality that requires the global filesystem namespace will be disabled. More concretely:
- fstream's open() function will be removed. - cstdio will no longer pull in fopen(), rename(), etc. - The test suite's get_temp_file_name() will be removed. This will cause all tests that use the global filesystem namespace to break, but will at least make all the other tests run (as get_temp_file_name will not build anyway).
It is important to mention that this change will make fstream rather useless on those systems for now. Still, I'd rather not have fstream disabled entirely, as it is of course possible to come up with an extension for fstream that would allow access to local filesystem namespaces (e.g., by adding an openat() member function).
Differential revision: http://reviews.llvm.org/D8194 Reviewed by: jroelofs (thanks!)
llvm-svn: 232049
show more ...
|