[Bug c++/115524] New: Cygwin: Space character categorized as non-printable by std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115524
Bug ID: 115524
Summary: Cygwin: Space character categorized as non-printable
by std::ctype
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
Created attachment 58451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58451=edit
test.cpp Demonstrate the bug
On Cygwin, a space character is reported as non-printable by
`std::ctype` in the "C" locale (the only locale supported by
libstdc+++ on Cygwin). In other words, the following expression evaluates to
`false`:
ctype.is(std::ctype_base::print, ctype.widen(' '))
where `ctype` is obtained by `std::use_facet>(loc)` and
`loc` is the "C" locale.
It should have been evaluated to `true` because a space character is required
by the C++ standard to be categorized as printable (the defining distinction
between a printable and a graphical character is that space is printable but
not graphical).
Also, the space character is reported as printable by `std::iswprint(int ch)`.
So it seems like the problem is specific to `libstdc++`.
Also, the non-wide space character is reported as printable, i.e,
`std::use_facet>(loc)::is(std::ctype_base::print, ' ')` is
`true`.
Also, `ctype.is(std::ctype_base::print, ctype.widen(' '))` is `true` with
MinGW, with GCC on Linux, and with Visual Studio.
The problem can be demonstrated with the code below (attached as `test.cpp`) in
regular Cygwin (https://cygwin.com/install.html) using GCC 12.3.1 and in the
Cygwin environment of MSYS2 (https://www.msys2.org/) using GCC 13.2.0:
#include
#include
#include
#include
int main()
{
using facet_type = std::ctype;
std::locale loc;
const auto& ctype = std::use_facet(loc);
wchar_t ch = ctype.widen(' ');
std::cout << ctype.is(ctype.print, ch) << "\n";
std::cout << (std::iswprint(std::char_traits::to_int_type(ch)) !=
0) << "\n";
}
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #14 from Kristian Spangsege
---
Is the underscore intended before `Guard` in `explicit _Guard(__c_locale) { }`
for the GLIBC <= 2.2 case?
Besides that, the full patch looks correct to me.
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 --- Comment #12 from Kristian Spangsege --- These changes look good to me. A couple of points: * Should the `else`s still be there now that the preceding branches terminate with `break`? * `do_out()` has the same problem as `do_in()`. * If there is already testing of `codecvt`, should a test be added for the "empty output" case? * This could break code that expects the incorrect behavior.
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 --- Comment #7 from Kristian Spangsege --- This bug still exists in GCC 14.0.1. This was tested with the attacked test_2.cpp. The actual result is `ok`, but it should have been `partial`. Curiously, this bug does not occur when using the Cygwin or MinGW versions of GCC. In these cases, the result is `partial` as it should be. I assume this is because on Cygwin and MinGW, libstdc++ uses a generic locale implementation that is different from the one ordinarily used on Linux.
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 --- Comment #6 from Kristian Spangsege --- Created attachment 58405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58405=edit Test whether bug still exists in GCC 14.0.1
[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063 --- Comment #6 from Kristian Spangsege --- Thanks for fixing it. Should it be back-ported to earlier GCC versions? From my point of view, as far back as GCC 11 would be nice.
[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063 --- Comment #1 from Kristian Spangsege --- By the way, and as expected, this problem does not exist in Clang.
[Bug c++/113063] New: Strange linker error in special case involving local class with defaulted spaceship operator and static assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063
Bug ID: 113063
Summary: Strange linker error in special case involving local
class with defaulted spaceship operator and static
assert
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
With the latest GCC (13.2) and also with GCC 11.4, the following C++ code
triggers a strange linker error:
#include
int main()
{
struct X {
auto operator<=>(const X&) const = default;
};
X x;
static_assert(noexcept(x < x));
static_cast(x < x);
}
Godbolt: https://godbolt.org/z/PfPfznT6Y
The linker error is this:
/usr/bin/ld: /tmp/ccsnSU59.o: in function `main::X::operator<=>(X const&)
const':
t.cpp:(.text+0x31): undefined reference to
`std::strong_ordering::strong_ordering(std::strong_ordering const&)'
It seems to be a bug that is triggered by the presence of the static assertion,
but only when the it occurs before the actual invocation of the less-than
comparison operation. Also, if the local class (`X`) is moved out of `main()`,
the problem goes away.
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 Kristian Spangsege changed: What|Removed |Added CC||kristian.spangsege at gmail dot co ||m --- Comment #5 from Kristian Spangsege --- This bug still exists in GCC 10.2, while libc++ (clang) appears to do the right thing. Specifically, when passing a nonzero amount of data (from_end > from) to std::codecvt::out(), but an empty output buffer (to_end == to), the return value is "ok". According to the C++ standard (C++17), the correct return value is "partial". This appears to happen regardless of locale. In particular, it happens in the C locale. As far as I can tell, http://cplusplus.github.io/LWG/lwg-closed.html#382 is not relevant here, because the current standard text is clear (C++17), and http://cplusplus.github.io/LWG/lwg-closed.html#382 has status NAD, which I assume means "not a defect". Jonathan, let me know if I am missing something.
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 --- Comment #3 from Kristian Spangsege --- I would recommend not locking arithmetic to std::uint32_t, and instead working with std::uint_fast32_t, because I can imaging a platform (current or future) where 32-bit arithmetic is slower that 64-bit arithmetic. As a bonus, the code will work on platforms that do not have std::uint32_t.
[Bug libstdc++/97311] New: Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 Bug ID: 97311 Summary: Bug in std::seed_seq::generate() when integer type has more than 32 bits Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kristian.spangsege at gmail dot com Target Milestone: --- As far as I can tell, std::seed_seq::generate() has a bug when _Type has more than 32 bits. The problem is that the following two additions can produce values greater than, or equal to 2**32: __begin[(__k + __p) % __n] += __r1; __begin[(__k + __q) % __n] += __r2; According to C++17 standard text, all operations must be performed modulo 2**32, so no generated value can be greater than, or equal to 2**32. It seems that a possible fix would be to change those two lines to something like this: __begin[(__k + __p) % __n] = __detail::__mod<_Type, __detail::_Shift<_Type, 32>::__value>(__begin[(__k + __p) % __n] + __r1)); __begin[(__k + __q) % __n] = __detail::__mod<_Type, __detail::_Shift<_Type, 32>::__value>(__begin[(__k + __q) % __n] + __r2));
