Project

General

Profile

Actions

Bug #19542

closed

Operations on zero-sized IO::Buffer are raising

Added by hanazuki (Kasumi Hanazuki) about 1 year ago. Updated 3 months ago.

Status:
Closed
Target version:
-
ruby -v:
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
Backport:
[ruby-core:112947]

Description

I found that IO::Buffer of zero length is not cloneable.

% ruby -v
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]

% ruby -e 'p IO::Buffer.for("").dup'
-e:1:in `initialize_copy': The buffer is not allocated! (IO::Buffer::AllocationError)
        from -e:1:in `initialize_dup'
        from -e:1:in `dup'
        from -e:1:in `<main>'

% ruby -e 'p IO::Buffer.new(0).dup'
-e:1: warning: IO::Buffer is experimental and both the Ruby and C interface may change in the future!
-e:1:in `initialize_copy': The buffer is not allocated! (IO::Buffer::AllocationError)
        from -e:1:in `initialize_dup'
        from -e:1:in `dup'
        from -e:1:in `<main>'

It seems IO::Buffer.new(0) allocates no memory for buffer on object creation and thus prohibits reading from or writing to it. So #dup method copying zero bytes into the new IO::Buffer raises the exception.
Empty buffers, however, often appear in corner cases of usual operations (encrypting an empty string, encoding an empty list of items into binary, etc.) and it would be easy if such cases could be handled consistently.

Other operations on NULL IO::Buffers are also useful but currently raising.

IO::Buffer.new(0) <=> IO::Buffer.new(1)
IO::Buffer.new(0).each(:U8).to_a
IO::Buffer.new(0).get_values([], 0)
IO::Buffer.new(0).set_values([], 0, [])

I'm not sure this is a bug or by design, but at least I don't want cloning and comparison to raise.


Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #18805: IO::Buffer is inconsistent when returning a string from an empty bufferClosedioquatix (Samuel Williams)Actions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0