[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:

[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

[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,

[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

[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

[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;`

[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]

[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

[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