https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #18 from Michel Morin ---
I tested on old mac systems, including the 32-bit version of MacOS X 10.5, and
confirmed that the `read` syscall with count = INT_MAX does not trigger EINVAL.
(Additionally, the same applies to the `write` s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #17 from Michel Morin ---
> I thought I saw some docs saying >= INT_MAX fails, but maybe I'm wrong.
> The Rust change uses INT_MAX - 1
The comment in the Rust code says
On OSX ... by rejecting any read with a size larger than or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118162
--- Comment #1 from Michel Morin ---
Strictly speaking the `writev` syscall with large counts (and the attached
testcase) succeed on macOS 10.xx. It seems that the restriction described in
manpage ("… return the following errors … the sum of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118162
Bug ID: 118162
Summary: ofstream::write(…, count) fails when count >= 2^31 on
darwin
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #15 from Michel Morin ---
FreeBSD's `read` manpage has been updated recently:
https://github.com/freebsd/freebsd-src/commit/3e95158
[2024-02-10] read.2: Describe debug.iosize_max_clamp
… read() … will succeed unless:
- The v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #14 from Michel Morin ---
Thanks, the committed version works fine too.
Note that `read` will fail when n > INT_MAX (without equality),
so we can define _GLIBCXX_MAX_READ_SIZE simply as __INT_MAX__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #11 from Michel Morin ---
Brilliant, I appreciate it!
I tested with an 8 GB file and confirmed that this fixes the issue on both
Intel and Apple silicon Macs.
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: li
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.
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, s
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 constr
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
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!
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).
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;` ->
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 .
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.o
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-
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
19 matches
Mail list logo
