YAML.load given an ISO8601 timestamp creates an incorrect value for usec
$ ruby1.8.7 -v -ryaml -e 'p YAML.load("2011-03-22t23:32:11.000000342222+01:00").usec'
ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-darwin9.8.0]
$ ruby1.9.2 -v -ryaml -e 'p YAML.load("2011-03-22t23:32:11.000000342222+01:00").usec'
ruby 1.9.2p180 (2011-02-18 revision 30909) [i386-darwin9.8.0]
$ ruby1.9 -v -ryaml -e 'p YAML.load("2011-03-22t23:32:11.000000342222+01:00").usec'
ruby 1.9.3dev (2011-04-12 trunk 31263) [i386-darwin9.8.0]
I believe these should be 0.
merges r31441,r31442 and r31443 from trunk into ruby_1_9_2.¶
YAML.load time correctly parse usecs smaller than 1 fixes #4571
Signed-off-by: URABE, Shyouhei firstname.lastname@example.org¶
ChangeLog for it¶
- ext/syck/rubyext.c (mktime_do): avoid buffer overrun, by silently ignoring lesser significant digits. Required buffer length can be computable so you might at first think of allocating enough memory space on the fly using alloca(). That is a wrong idea because when using alloca there is always risk of integer overflow. A function that accepts outer-process resources like this should not blindly trust its inputs. In this particular case we just want to generate miliseconds resolution by strtod() so the string in question needs no more length than what we originally have. Ignoring lesser significant digits should suffice I believe.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_1_9_2@31831 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Updated by tenderlovemaking (Aaron Patterson) over 8 years ago
- ruby -v changed from ruby 1.9.3dev (2011-04-12 trunk 31263) [i386-darwin9.8.0] to -
Updated by shyouhei (Shyouhei Urabe) over 8 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100