History log of /llvm-project/libcxx/include/cstdio (Results 1 – 25 of 35)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12