| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes using non-default locales, which currently can crash when
e.g. formatting numbers.
Within the localeconv_l function, the per-thread locale is temporarily
changed with __libcpp_locale_guard, then localeconv() is called,
returning an lconv * struct pointer.
When localeconv_l returns, the __libcpp_locale_guard dtor restores
the per-thread locale back to the original. This invalidates the
contents of the earlier returned lconv struct, and all C strings
that are pointed to within it are also invalidated.
Thus, to have an actually working localeconv_l function, the
function needs to allocate some sort of storage for the returned
contents, that stays valid for as long as the caller needs to use
the returned struct.
Extend the libcxx/win32 specific locale_t class with storage for
a deep copy of a lconv struct, and change localeconv_l to take
a reference to the locale_t, to allow it to store the returned
lconv struct there.
This works fine for libcxx itself, but wouldn't necessarily be right
for a caller that uses libcxx's localeconv_l function.
This fixes around 11 of libcxx's currently failing tests on windows.
Differential Revision: https://reviews.llvm.org/D69505
(cherry picked from commit 7db4f2c6945a24a7d81dad3362700353e2ec369e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with msvcrt.dll
This also makes this function consistent with the rest of the
libc++ provided fallbacks.
The locale support in msvcrt.dll is very limited anyway; it can
only be configured processwide, not per thread, and it only seems
to support the locales "C" and "" (the user set locale), so it's
hard to make any meaningful automatic test for it. But manually tested,
this change does make time formatting locale code in libc++ output
times in the user requested format, when using locale "".
Differential Revision: https://reviews.llvm.org/D69554
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.
In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.
This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).
In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits, christof, carwil
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63328
llvm-svn: 364012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the output buffer is too small to contain the output, `vsnprintf()`
fills the buffer and returns the number of characters that __would have__
been written if the buffer was sufficiently large.
`_vnsprintf_s()` on the other hand fills the buffer and returns -1 when this
happens. We want the former behavior, but we also want to be able to
pass in a locale to prevent having to call `setlocale()`.
`__stdio_common_vsprintf()` is the only function general enough to get
the behavior we want.
Differential Revision: https://reviews.llvm.org/D59727
llvm-svn: 357024
|
| |
|
|
|
|
|
|
|
|
|
| |
The issue is that __libcpp_locale_guard makes some slow calls to setlocale().
This change avoids using __libcpp_locale_guard in snprintf_l().
Fixes https://bugs.llvm.org/show_bug.cgi?id=41131
Differential Revision: https://reviews.llvm.org/D59525
llvm-svn: 356512
|
| |
|
|
|
|
| |
output buffers correctly' which has been hanging around for a long time
llvm-svn: 351971
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a warning like this:
warning: comparison of integers of different signs:
'std::__1::__libcpp_tls_key' (aka 'long') and 'DWORD'
(aka 'unsigned long') [-Wsign-compare]
if (*__key == FLS_OUT_OF_INDEXES)
~~~~~~ ^ ~~~~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D49782
llvm-svn: 337946
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_LIBCPP_INLINE_VISIBILITY
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_LIBCPP_INLINE_VISIBILITY"
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
llvm-svn: 336382
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336369
|
| |
|
|
|
|
|
|
|
|
|
| |
The language standard does not define a function with this name,
so it is part of the user's namespace. This change fixes a duplicate
symbol error that occurs when a user attempts to define a function
with this name.
Differential Revision: https://reviews.llvm.org/D42405
llvm-svn: 323237
|
| |
|
|
|
|
|
|
|
| |
This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.
Differential Revision: https://reviews.llvm.org/D42214
llvm-svn: 323169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the problem PR31516 with setting locale on Windows by wrapping
_locale_t with a pointer-like class.
Reduces 74 test failures in std/localization test suite to 47 test
failures (on llvm clang, Visual Studio 2015). Number of test failures
doesn't depend on the platform (x86 or x64).
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40181
llvm-svn: 318902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch corrects the build errors I encountered when building on MinGW64.
Reviewers: mati865, rnk, compnerd, smeenai, bcraig
Reviewed By: mati865, smeenai
Subscribers: martell, chapuni, cfe-commits
Differential Revision: https://reviews.llvm.org/D33082
llvm-svn: 304360
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously <locale> used std::unique_ptr<remove_ptr<locale_t>, locale-mgmt-function>
as a scope guard for (A) creating new locales, and (B) setting the thread specific locale
in RAII safe manner.
However using unique_ptr has some problems, first it requires that locale_t is a pointer
type, which may not be the case (Windows will need a non-pointer locale_t type that emulates _locale_t).
The second problem is that users of the guards had to supply the locale management function to the custom
deleter at every call site. However these locale management functions don't exist natively Windows, making
a good Windows implementation of locale more difficult.
This patch creates distinct and simply RAII guards that replace unique_ptr. These guards handle calling
the correct locale management function so that callers don't have too. This simplification will
aid in upcoming Windows fixes.
llvm-svn: 302474
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
The locale structures have been made opaque in CRT 14+. This currently
prevents building libc++ for Windows. We can re-enable this in the
future when we have replicated the structure to access the private field
for the name (unless there exists a better supported mechanism to query
the name of a locale given the locale_t).
llvm-svn: 290835
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `_LIBCPP_NO_EXCEPTIONS` is defined, we end up with compile errors
when targeting MSVCRT:
* Code includes `<new>`
* `<new>` includes `<cstdlib>` in order to get `abort`
* `<cstdlib>` includes `<stdlib.h>`, _before_ the `using ::abort`
* `<stdlib.h>` includes `locale_win32.h`
* `locale_win32.h` includes `<memory>`
* `<memory>` includes `<stdexcept>`
* `<stdexcept>` includes `<cstdlib` for `abort`, but that inclusion gets
(correctly) ignored because of header guards
* `<stdexcept>` references `_VSTD::abort`, which isn't declared
The easiest solution is to make `locale_win32.h` not include `<memory>`,
by removing the use of `unique_ptr` and manually restoring the locale
instead.
Differential Revision: https://reviews.llvm.org/D24374
llvm-svn: 281641
|
| |
|
|
| |
llvm-svn: 208869
|
| |
|
|
|
|
|
|
|
|
|
| |
functions in src/support/win32/locale_win32.cpp and locale_win32.h,
calling upon vsnprintf for which there is a MingW correct alternative.
Note! __USE_MINGW_ANSI_STDIO is not modified in this patch. In order to
use the __mingw version it must be defined before including the MingW
headers.
llvm-svn: 195044
|
| |
|
|
| |
llvm-svn: 189273
|
| |
|
|
| |
llvm-svn: 185865
|
| |
|
|
|
|
| |
It also refactors repetitive code in string.cpp do greatly reduce the repetitiveness, increasing maintainability.
llvm-svn: 182026
|
| |
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130325/077133.html
llvm-svn: 178581
|
| |
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130325/077132.html
llvm-svn: 178545
|
| |
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130325/077131.html
llvm-svn: 178544
|
| |
|
|
| |
llvm-svn: 142732
|
| |
|
|
| |
llvm-svn: 142237
|
| |
|
|
| |
llvm-svn: 140805
|
| |
|
|
| |
llvm-svn: 140728
|
| |
|
|
| |
llvm-svn: 140384
|
|
|
llvm-svn: 140328
|
