#gsub! mutates frozen strings

[binary42@…]

If a string is frozen, #sub! and #gsub! raise a RuntimeError. It seems other bang methods like succ! are affected as well.

[lsansonetti@…]

I do not understand the problem. The subject says that bang methods mutate frozen strings, and the description says the contrary (that a RuntimeError is raised when trying to mutate a frozen string).

In any way, the good behavior is that frozen strings should not be modifiable, and this is what MacRuby is currently doing (as well as 1.8 and 1.9).

$ ruby -ve 's="foo";s.freeze;s.gsub!(/./, "x")'
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
-e:1:in `gsub!': can't modify frozen string (TypeError)
	from -e:1

$ macirb
>> s='foo'
=> "foo"
>> s.sub!(/./, 'x')
=> "xoo"
>> s.freeze
=> "xoo"
>> s.sub!(/./, 'x')
RuntimeError: can't modify frozen string
	from (irb):4:in `sub!'
	from (irb):4
	from /usr/local/bin/macirb:12:in `<main>'
>> 

Also, note that if you build a non-mutable NSString by yourself, bang operations will also result in a RuntimeError.

>> s = NSString.new
=> ""
>> s.clear
RuntimeError: can't modify immutable string
	from (irb):6:in `clear'
	from (irb):6
	from /usr/local/bin/macirb:12:in `<main>'
>> s = NSMutableString.new
=> ""
>> s.clear
=> ""
>> 

[binary42@…]

I typoed the original message. I meant it should raise the RuntimeError. And you are certainly right about the current behavior of sub!. I must have made an error in testing that method. #gsub!, however, is still mutating the string.

(sorry for the confusion)

[lsansonetti@…]

Good catch! #gsub! indeed does mutate the frozen string.

$ ./miniruby -ve 's="foo";s.freeze;s.gsub!(/./,"x");p s'
MacRuby version 0.2 (ruby 1.9.0 2008-05-17) [universal-darwin9.0]
"xxx"
$ 

[lsansonetti@…]

Should be fixed in r234/trunk.

$ ./miniruby -ve 's="foo";s.freeze;s.gsub!(/./,"x");p s'
MacRuby version 0.2 (ruby 1.9.0 2008-05-17) [universal-darwin9.0]
-e:1:in `gsub!': can't modify frozen string (RuntimeError)
	from -e:1:in `<main>'