Ruby-dev summary 27761-28026

Ruby
1

Hi,

This is ruby-dev summary 27761-28026.

lity information (webrick, xmlrpc)

Matz reported two vulnerabilities about webrick and xmlrpc (These
problems allow DoS attack) on ruby 1.8.2 or earlier. Problems were
fixed on ruby 1.8.3, so it is recommended for all to use ruby 1.8.3 or
later. There are also patches for ruby 1.8.2.

ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.2-webrick-dos-1.patch
ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.2-xmlrpc-dos-1.patch

Details of these problems will be posted independently.

[ruby-dev:27794] sample/svr.rb DoS vulnerability

Akira T. reported DoS attack vulnerability of sample/svr.rb. He
also reported following sequence to reproduce DoS attack.

For more detail, see [ruby-dev:27794].

[ruby-dev:27795] DRb DoS vulnerability

Akira T. also pointed out DoS attack vulnerability on DRb.

For more detail, see [ruby-dev:27795].

BTW, above 4 vulnerabilities are all reported by Akira T..

[ruby-dev:27871] Numeric and Complex

Matz requested for comments about following problem:

Ruby’s Numeric class includes Comparable module. This is based on
assumption that values are linear. However Complex value is not linear.
Current implementation of Complex#<=> is based on Complex#abs, but
Complex value is used as Range bound.

To solve this problem, Matz proposed following solutions:

  • Make new super class of Integer, Float, Rational, etc.
    New class includes Comparable.
  • All of classes (Integer, Float, Rational) includes Comparable.
  • Change Complex super class other than Numeric.
  • Keeping things as they are.

After active discussion, Matz decided follows:

  • undef Complex#<=>
  • add a new method Numeric#scalar?

[ruby-dev:27890] rb_funcall2() for protected method

Nobuyoshi N. proposed that rb_funcall2() should invoke protected
method (with a patch to change this behavior).

Matz accepted this change. And this change enable us to run an example
of [ruby-talk:169057].

[ruby-dev:27904] ruby 1.8.4 preview2

ruby 1.8.4 preview2 was released.

ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.4-preview2.tar.gz
MD5: e5a48054fb34f09da17e8e8f04b8c706

This is also announced at [ruby-core:06798] ruby 1.8.4 preview2
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/06798

If you have time, please check this preview2.

[ruby-dev:27972] A Sample of Ruby/Tk

Hidetoshi NAGAI proposed to commit a sample of Ruby/Tk which posted at
[ruby-talk:169227] because this sample seems useful.

Matz accepted to commit it in ruby 1.8.4.

[ruby-dev:27984] modified restarg with zsuper

Koichi Sasada proposed that following example should not raise
ArgumentError because “super” should work as “super(a, *b)” in this
case.

class C
  def m(a, b)
  end
end

class D < C
  def m(a, *b)
    b[0] ||= 2 # if no rest arguments are given, add one
    super
  end
end

D.new.m(1, 2)  # OK, no problem

D.new.m(1)
# wrong number of arguments (1 for 2) (ArgumentError)
# in current interpreter (1.9.0)

Matz agreed this proposal.

Current YARV performs this behavior :slight_smile:

[ruby-dev:27991] GC.always

Akira T. proposed “GC.always” method. This method forces ruby
interpreter to invoke GC whenever it is invokable. It means that GC
will be invoked at every object allocations, every memory allocations.
This feature helps interpreter debugging around GC bugs.

Matz refused “GC.always” method name (didn’t refused this feature, only
method name). Another proposed method name is “GC.debug”.

This issue is still open.

[ruby-dev:27996] How about “Time Literal”?

take_tk proposed that “Time Literal” represented by ISO 8601. For
example, 19850412T101530 means Time object as “12 Apr 1985 10:15:30”.

This issue is still open.

ruby-dev summary index: ruby-dev summary

2

SASADA Koichi wrote:
…

This issue is still open.
This would be helpful for extension writers. Would the method take a
block, to turn on the feature only for suspect code?

GC.every_allocation
GC.aggressive
GC.eager
GC.leave_no_garbage_behind
GC.fanatically_tidy

Come on creative people, this is a softball question!

3

On Tue, 20 Dec 2005, Joel VanderWerf wrote:

method name). Another proposed method name is “GC.debug”.
GC.fanatically_tidy

Come on creative people, this is a softball question!

i really, really prefer an options based approach to these kinds of
things.
when you have to pick a name for every method the development is slowed.
pick
a catch-all and configure it:

GC.gc(:mode => “every”) do

end

next week, when someone wants a new feature, it can be added it without
changing a thing:

GC.gc(:mode => “every”, :pool => MyCustomPool) do

end

etc.

food for thought.

-a

4

On Dec 19, 2005, at 11:08 AM, [email protected] wrote:

Matz refused “GC.always” method name (didn’t refused this
GC.gc(:mode => “every”) do
end
YAGNI

–
Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

5

On Dec 19, 2005, at 11:52 AM, Joel VanderWerf wrote:

end

YAGN what? GC.always or an options hash?

Somebody needs GC.always to help with debugging. The options hash
falls under YAGNI.

–
Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

6

In article [email protected], SASADA Koichi [email protected]
wrote:

assumption that values are linear. However Complex value is not linear.
Current implementation of Complex#<=> is based on Complex#abs, but
Complex value is used as Range bound.

So basically, the current method compares the magnitude of the complex
numbers
interpreted to be a vector of two values. (or in other words, the
length of
the hypotenuse is compared). Why is that problematic? Seems like a
reasonable interpretation.

  • undef Complex#<=>
  • add a new method Numeric#scalar?

Well, maybe Complex should be derived from a Vector (in the Mathematical
sense) class? Vector ‘has’ Numeric types. Not sure if a common base
class
between Vector and Numeric is needed (I think probably not).

A Complex would be a Vector with two Numerics, but people using Vector
directly could create a vector with any number of Numerics. So Complex
would
just be a special case of Vector with 2 values and some nice “to_s”
functionality.

Phil

7

Eric H. wrote:

will be invoked at every object allocations, every memory allocations.
slowed. pick
GC.gc(:mode => “every”, :pool => MyCustomPool) do

end

YAGNI

YAGN what? GC.always or an options hash?

8

On Tue, 20 Dec 2005, Eric H. wrote:

YAGN what? GC.always or an options hash?

Somebody needs GC.always to help with debugging. The options hash falls
under YAGNI.

i disagree. this thread shows that, had the original interface been
option
based, we’d not need a new one. i know the theory, but consider how
difficult
it is to convince matz of a good name - minimizing names minimizes the
convincing.

-a

9

On Dec 19, 2005, at 1:59 PM, [email protected] wrote:

how difficult
it is to convince matz of a good name - minimizing names minimizes the
convincing.

How does an options hash remove the problem of finding a good name?

There are exactly four methods on GC, 3 class, 1 instance:

$ ruby -e ‘p GC.methods.sort - Object.methods’
[“disable”, “enable”, “start”]
$ ruby -e ‘p GC.instance_methods.sort - Object.methods’
[“garbage_collect”]

So GC isn’t really full of names that we can’t use because they’re
taken. Picking the right name for the feature hasn’t gone away
because we’re using an options hash.

So if you use an options hash you now have as much as twice as many
names to choose. Also, an options hash forces the programmer to
remember twice as much, since they must remember both the key and the
value (maybe more, since they must remember which method to call as
well).

Your proposal was:

GC.gc(:mode => “every”) do … end

GC::gc isn’t a very good method name for specifying garbage
collection options, maybe GC::options instead.

:mode looks good, but “every” is just as bad as “always”. It has a
similar problem to “always”, “What does GC always mean? After every
expression?”, for “every”, “GC every what?”. Plus, there is the
non-“every” mode, what do we call it?

By moving to an options hash you’ve made the problem bigger for what
gain? This is the first new method on GC in one month shy of seven
years. (Yes, the API for the GC hasn’t changed since it was checked
in.) I don’t think that an options hash is a prudent choice when the
API remains unchanged for so long.

Also, I cannot think of any core libraries that use an options hash.

–
Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com