[Bug libstdc++/110190] New: regex: incorrect match results on DFA engines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110190
Bug ID: 110190
Summary: regex: incorrect match results on DFA engines
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
libstdc++ makes incorrect matches with the sample code in
https://en.cppreference.com/w/cpp/regex/syntax_option_type . (Though the
description of the "leftmost longest rule" is not correct in that page, their
expected results are fine).
Here is a slightly shorter version:
#include
#include
#include
int main()
{
std::string text = "regexp";
std::regex re(".*(ex|gexp)", std::regex::extended);
std::smatch m;
std::regex_search(text, m, re);
std::cout << m[0] << '\n'; // => should be "regexp" on DFA engines
}
This should print "regexp", but libstdc++ prints "regex". (libc++ works fine.)
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #9 from Michel Morin --- > (which even mentions the std::string((const char*)nullptr) case): > https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html Oh, that's good to know. Understood that PEDASSERT fits better. > can we add a "pednonnull" attribute or something to produce a -Wnonnull > warning like the nonnull attribute but w/o affecting code generation as well? I think such an attribute (like Clang's _Nonnull) would be a nice addition. So I grepped Nonnull on libc++, but strangely there are __no__ uses of _Nonnull/__nonnull. I only found a few __gnu__::__nonnull__ in __memory_resource/memory_resource.h. In libc++, std::string constructors have assertions for nullptr check, but there are no attributes.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #6 from Michel Morin --- True. Detectable is not correct — that's "maybe-detectable" at most, and the bug is not silent. In a code that I checked, the buggy code (`std::cout << NullCharPtr;`) is the last printing call to std::cout, so I failed to see the side-effect. The patchlet using `_GLIBCXX_DEBUG_PEDASSERT` works fine. Actually I would like `_GLIBCXX_DEBUG_ASSERT` (because I've been using `_GLIBCXX_DEBUG` but never `_GLIBCXX_DEBUG_PEDANTIC`), but I guess using `_GLIBCXX_DEBUG_PEDASSERT` rather than `_GLIBCXX_DEBUG_ASSERT` in this case is a delibarate choice.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #3 from Michel Morin --- >From the safety point of view, I agree with you. But, at the same time, I thought that detectable UB (with the help of sanitizers) is useful than silent bug. How about `throw`ing as in std::string's constructor?
[Bug libstdc++/109891] New: Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
Bug ID: 109891
Summary: Null pointer special handling in ostream's operator <<
for C-strings
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
This code
#include
int main() { std::cout << (char*)nullptr; }
does not cause any bad things (like SEGV), because libstdc++'s
operator<<(ostream, char const*) has special handling of null pointers:
template
inline basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __out, const _CharT* __s)
{
if (!__s)
__out.setstate(ios_base::badbit);
else
__ostream_insert(...);
return __out;
}
Passing a null pointer to this operator is a precondition violation, so the
current implementation perfectly conforms to the C++ standard. But, why don't
we remove this special handling? By doing so, we get
- better interoperability with toolings (i.e. sanitizers can find the bug
easily)
- unnoticeable performace improvement
and we lose
- deterministic behaviors (of poor codes) on a particular stdlib
I believe the first point makes more sense than the last point.
It seems that old special handling `if (s == NULL) s = "(null)";`
(https://github.com/gcc-mirror/gcc/blob/6599da0/libio/iostream.cc#L638) was
removed in GCC 3.0, but reintroduced (in the current form) in GCC 3.2 in
response to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6518 .
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #5 from Michel Morin --- Confirmed the fix. Will send a patch to ML. > I had use -std=c++98 This comment helps me a lot to understand what's going on. Thanks!
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #4 from Michel Morin --- It seems that the reason is: `cp_keyword_starts_decl_specifier_p` in `cp/parser.c` does not include `RID_TYPENAME`. Note that `typedef` is a decl-specifier ([dcl.spec] p.1 in the Standard).
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #3 from Michel Morin --- There is a typo in this PR's Description. Here is a more readable one: When we enable `typeof` GCC extension (e.g. using `-std=gnu++**` options), we get strange did-you-mean suggestions. `typdef int Int;` -> error: 'typdef' does not name a type; did you mean 'typeof'? `typedeff int Int;` -> error: 'typedeff' does not name a type; did you mean 'typeof'? Confirmed on GCC 11.2.
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #5 from Michel Morin --- I put a wrong link for Rust's PR. The correct link is https://github.com/rust-lang/rust/pull/38622 .
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #4 from Michel Morin --- I googled and found that Rust and Python had the same issue (and fixed it): [Rust] https://github.com/rust-lang/rust/issues/38590 (PR: https://github.com/ziglang/zig/pull/6333) [Python] https://bugs.python.org/issue24658 (PR: https://github.com/python/cpython/pull/1705) These bug reports also says that the darwin's `write(…, …, nbyte)` fails when nbyte > INT_MAX, and I confirmed that. > Maybe they do a loop around the read for sizes >= INT_MAX. Sounds good to me.
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #2 from Michel Morin --- Whoa, darwin's (and FreeBSD's too?) `read(…, …, nbyte)` fails when nbyte >= 2^31! This is the culprit, I think. I also found the following description in FreeBSD's manpage of read (https://www.unix.com/man-page/FreeBSD/2/read/): ERRORS [EINVAL] The value nbytes is greater than INT_MAX. Given that the testcase works file when compiled with Clang, libcxx would have some workround for it.
[Bug libstdc++/102259] New: ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
Bug ID: 102259
Summary: ifstream::read(…, count) fails when count >= 2^31 on
darwin
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
Created attachment 51431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51431=edit
Testcase for ifstream::read(…, count >= 2^31)
I tried to read a large file using `ifstream::read` on Mac, but it fails to
read any byte when count >= 2^31. Note that the system is 64-bit and
`std::streamsize` has 8 bytes.
Here is a testcase.
#include
#include
int main() {
std::ifstream is{"2GB.bin", std::ios::binary}; // filesize >= 2^31 bytes
auto buffer = new char[1LL << 31];
is.read(buffer, 1LL << 31);
std::cout << is.good() << " (" << is.gcount() << " bytes)\n";
// Expected output: "1 (2147483648 bytes)"
// Actual output (on Mac): "0 (0 bytes)"
}
My system is macOS 10.15 running on x86_64 Mac. The testcase failed on
Homebrew's GCC (ver. 6, 9, 10, 11) and MacPorts' GCC (ver. 6), but it succeeded
on LLVM Clang (trunk) and Apple Clang (ver. 12).
`ifstream::read(…, count)` works fine when count < 2^31. So if we split
is.read(buffer, 1LL << 31);
into
is.read(buffer, (1LL << 31) - 1);
is.read(buffer + (1LL << 31) - 1, 1);
then everything goes OK.
Additionally, `istringstream::read(…, count >= 2^31)` works fine both on GCC
and Clang.
I don't think this simple issue went unnoticed, so maybe I've missed something.
