summaryrefslogtreecommitdiff
path: root/libcxx/include/cstdio
AgeCommit message (Collapse)Author
2024-12-21[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)Nikolas Klauser
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.
2024-12-10[libc++] Add #if 0 block to all the top-level headers (#119234)Nikolas Klauser
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.
2024-09-05[libc++][modules] Modularize <cstddef> (#107254)Louis Dionne
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.
2024-02-29[libc++] Clean up includes of <__assert> (#80091)Louis Dionne
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
2024-01-10[libc++] Remove _LIBCPP_C_HAS_NO_GETS (#77346)Louis Dionne
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.
2023-11-13[libc++] Remove _LIBCPP_HAS_NO_FGETPOS_FSETPOS (#72073)Louis Dionne
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.
2022-08-17[libc++] Diagnose when header search paths are set up incorrectlyLouis Dionne
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
2022-03-30[libc++] Ensure that all public C++ headers include <__assert>Louis Dionne
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
2022-02-04[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Arthur O'Dwyer
Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800
2021-11-17[runtimes][NFC] Remove filenames at the top of the license noticeLouis Dionne
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.
2021-08-24[libc++] Remove support for CloudABI, which has been abandonedLouis Dionne
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
2021-06-04[libc++] Use the using_if_exists attribute when providedLouis Dionne
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
2021-04-20[libc++] NFC: Normalize `#endif //` comment indentationLouis Dionne
2020-04-16Reland: Don't expose unavailable cstdio functions.Dan Albert
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
2020-04-07Revert "Don't expose unavailable cstdio functions."Dan Albert
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.
2020-04-07Don't expose unavailable cstdio functions.Dan Albert
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
2019-09-07Remove ::gets for FreeBSD 13 and laterDimitry Andric
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
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2017-04-07[libc++] Drop support for CRTs older than VS 2015Shoaib Meenai
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
2016-11-08[libc++] Remove unnecessary MSVCRT exclusionsShoaib Meenai
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
2016-09-01cstdio: limit gets to CRT versions below 14Saleem Abdulrasool
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
2015-10-09Split <stdio.h> out of <cstdio>.Richard Smith
As with <stddef.h>, skip our custom header if __need_FILE or __need___FILE is defined. llvm-svn: 249798
2015-10-06Remove unnecessary inline functions capturing the contents of C library macros.Richard Smith
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
2015-03-26Make the presence of stdin and stdout optional.Ed Schouten
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
2015-03-12Add option to disable access to the global filesystem namespace.Ed Schouten
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
2015-01-10Support Newlib as libc++'s C library [cstdio part, part 2]Jonathan Roelofs
Wrappers for clearerr, feof, ferror (which newlib implements as macros). http://reviews.llvm.org/D5420 llvm-svn: 225563
2013-10-12Implement national body comment GB9: remove std::getsMarshall Clow
llvm-svn: 192538
2013-09-17G M: Restore the ability for libcxx to compile again on mingw 64.Howard Hinnant
llvm-svn: 190837
2013-08-01Nico Rieck: Currently _MSC_VER and _WIN32 are used to guard code which isHoward Hinnant
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can also define _MSC_VER, and MSVCRT is not necessarily the only C runtime, these macros should not be used interchangeably. This patch divides all Windows-related bits into the aforementioned categories. Two new macros are introduced: - _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using _MSC_VER, excluding Clang. - _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default when _WIN32 is defined. This leaves _WIN32 for code using the Windows API. This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF. Nico, please prepare a patch for CREDITS.TXT, thanks. llvm-svn: 187593
2012-07-26Patch by Andrew C. Morrow: shims to work around macroized getc and putc on ↵Howard Hinnant
linux. On my eglibc 2.13 based Debian system 'getc' is a macro defined in /usr/include/stdio.h. This decision to make it a macro doesn't seem to be guarded by any feature test macro as far as I can see. llvm-svn: 160799
2011-10-22More windows port work by Ruben Van BoxemHoward Hinnant
llvm-svn: 142732
2011-10-17Windows support by Ruben Van Boxem.Howard Hinnant
llvm-svn: 142235
2010-11-16license changeHoward Hinnant
llvm-svn: 119395
2010-05-11Wiped out some non-ascii characters that snuck into the copyright.Howard Hinnant
llvm-svn: 103516
2010-05-11libcxx initial importHoward Hinnant
llvm-svn: 103490