Add specs for all of IO::Buffer constructors

[trinistr]

Continuing from #1297

• Added a spec for .map. It has a lot of edge cases.
  • In my opinion, basically all cases which result in a syscall error are undefined behavior, but most of them at least can be specified. Concrete errors are not specified due to differences between systems.
  • Offset and size were not really checked before Fix multiple bugs in IO::Buffer.map and update its documentation ruby#15264 (which should land in Ruby 4.0).
• Added specs for .for and .string. Not much to say about these, they behave according to documentation and don't have complicated arguments.
• Added more cases for #initialize (.new).
• Removed most cases for predicate methods, leaving just a few representative examples, as flags are checked in constructor specs.

---

More weird stuff:

• .map:
  • Specifying non-0 offset guarantees that everything breaks: size is computed incorrectly, crashing VM on reading the whole buffer, on macOS even a bounded read crashes VM, on Windows valid sizes are ???
    • https://bugs.ruby-lang.org/issues/21700
    • Fix multiple bugs in IO::Buffer.map and update its documentation ruby#15264
  • size can be larger than file's size, which may somewhat work on some systems or cause crashes on access.
    • Fix multiple bugs in IO::Buffer.map and update its documentation ruby#15264 prohibits this.
• .new:
  • Passing LOCKED flag is intended? There is a test for that. But this seems like a bad idea to me, as it's not freeable (GC can still free it, though, I think).

[eregon]

@ioquatix Could you review this maybe?

[trinistr]

@ioquatix Could you review this maybe?

This is still a very early draft, but that offset parameter made me create an issue and a PR to ruby directly, so, yeah 🥹 Reviewing the PR with fixes for the method is probably more useful currently.

[eregon]

LGTM in general

[eregon]

Just needs a couple tweaks

[eregon]

FYI there were a bunch of failures on https://rubyci.org/ caused by these specs, e.g.
https://rubyci.s3.amazonaws.com/debian/ruby-master/log/20260129T063003Z.fail.html.gz
http://rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20260129T063005Z.fail.html.gz
http://rubyci.s3.amazonaws.com/freebsd13/ruby-master/log/20260129T083001Z.fail.html.gz
http://rubyci.s3.amazonaws.com/freebsd14/ruby-master/log/20260129T083002Z.fail.html.gz
http://rubyci.s3.amazonaws.com/freebsd15-arm/ruby-master/log/20260129T043002Z.fail.html.gz
http://rubyci.s3.amazonaws.com/s390x/ruby-master/log/20260129T060003Z.fail.html.gz

@nobu fixed them in ruby/ruby@cd26647...e48ed4b, thank you and sorry. I think the remaining failures are just waiting for new CI runs.

I'm guessing the reasons for the CI in repo not catching that is:

• I think some of RubyCI don't have a locale set, or equivalent to LC_ALL=C/LANG=C. We should add a CI job here to catch this earlier: Add a CI job to run specs with LC_ALL=C #1336
• mmap() seems quite inconsistent how it behaves on various platforms. That's how it is and it sucks (I've had the same experience or even worse with clock_getres(), that's basically broken in some way one very platform), but I think the only thing we can do is be careful to not be overly specific about e.g. system errors or behavior for edge cases. To the extent possible I think would make sense for Ruby to shield us from this variability by having reliable checks e.g. for size 0, incorrect offset, etc, cc @ioquatix.

[trinistr]

Oof, didn't expect that there would be this many problems, sorry everyone 🙇

To the extent possible I think would make sense for Ruby to shield us from this variability by having reliable checks e.g. for size 0, incorrect offset, etc

Almost all UB cases are already checked in 4.0. As far as I'm aware, the only major problem left is unreliability of allowed values for offset (https://bugs.ruby-lang.org/issues/21700).
But it looks like I was too optimistic about mmap raising some error in these cases.

http://rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20260129T063005Z.fail.html.gz

I see failures on OpenBSD related to sharing mmaped memory across processes, curious. Don't see anything in documentation for why it wouldn't be shared. @eregon Should I disable it in ruby/spec?

[eregon]

I think the BSD failure is just a run on an old commit, I expect it's fixed when the CI runs on a newer ruby/ruby commit.

[trinistr]

Alright, we will see, I guess.

[eregon]

Mmh indeed it still happens and only on OpenBSD, I'll exclude that spec on OpenBSD for now.