[ruby-core:112947] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[ruby-core:112947] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[hanazuki (Kasumi Hanazuki) via ruby-core]

Issue #19542 has been reported by hanazuki (Kasumi Hanazuki).

----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542

* Author: hanazuki (Kasumi Hanazuki)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:116193] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[ioquatix (Samuel Williams) via ruby-core]

Issue #19542 has been updated by ioquatix (Samuel Williams).


I am okay to make this work as you propose, however it should be noted, in C, you cannot provide `NULL` and size=0 to memcpy or similar functions (see https://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0 for some discussion on the topic).

I agree, it is a little confusing.

I'll make a PR to adjust this behaviour and we can see if there are any potential issues.

----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542#change-106207

* Author: hanazuki (Kasumi Hanazuki)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:116194] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[ioquatix (Samuel Williams) via ruby-core]

Issue #19542 has been updated by ioquatix (Samuel Williams).


See https://github.com/ruby/ruby/pull/9532 for the proposed changes.

----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542#change-106210

* Author: hanazuki (Kasumi Hanazuki)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:116205] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[ioquatix (Samuel Williams) via ruby-core]

Issue #19542 has been updated by ioquatix (Samuel Williams).

Status changed from Open to Closed
Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN to 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED

Applied in https://github.com/ruby/ruby/commit/c5cf4d4e129f64cb69aaf0a829aed068ef1943c4

----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542#change-106223

* Author: hanazuki (Kasumi Hanazuki)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:116207] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[ioquatix (Samuel Williams) via ruby-core]

Issue #19542 has been updated by ioquatix (Samuel Williams).

Assignee set to ioquatix (Samuel Williams)

----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542#change-106226

* Author: hanazuki (Kasumi Hanazuki)
* Status: Closed
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 3.3: REQUIRED
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:116588] [Ruby master Bug#19542] Operations on zero-sized IO::Buffer are raising

[naruse (Yui NARUSE) via ruby-core]

Issue #19542 has been updated by naruse (Yui NARUSE).

Backport changed from 3.3: REQUIRED to 3.3: DONE

ruby_3_3 d7dc57a545d75c01313a9020b162ebb648a3ea18 merged revision(s) c5cf4d4e129f64cb69aaf0a829aed068ef1943c4.

----------------------------------------
Bug #19542: Operations on zero-sized IO::Buffer are raising
https://bugs.ruby-lang.org/issues/19542#change-106601

* Author: hanazuki (Kasumi Hanazuki)
* Status: Closed
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
* Backport: 3.3: DONE
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/