inifile icon indicating copy to clipboard operation
inifile copied to clipboard

Bad value parse in IniFile Gem

Open e-gris opened this issue 7 years ago • 1 comments

A carefully (or accidentally) crafted value can cause Inifile#load to become confused when it apparently incorrectly parses a string as a scientific notation value.

This script should print "2017.1_26_57e7669". Instead it prints "Infinity" (ruby 2.4.0 on CentOs 7)

#!/usr/bin/env ruby

require 'inifile'

inifile = IniFile.new(:filename => "file.ini") inifile['global'] = { "buggystuff" => "2017.1_26_57e7669" } inifile.write

inifile2 = IniFile.load("file.ini") global = inifile2["global"] p global["buggystuff"]

e-gris avatar Mar 11 '17 00:03 e-gris

This is due to the way that typecasting is currently handled.

Another example of a numeric that gets mangled by this is when an INI file contains an integer-like value that should not be considered a number. For example, a five-character US postal code like 02719. This is not a number, and 02719 is not equivalent to 2719.

Because inifile attempts to type cast all values using the same process, sometimes the results are unexpected. When the typecasting tries to convert the value to an integer (Integer("02719")), it fails, because Integer treats that string as an octal number value, and since it contains digits that are outside the bounds of an octal number it fails. It then tries Float("02719"). Float and Integer handle things differently, and Float does not treat the value like an octal number. It parses it just a standard decimal, and yields 2719.0. Even if Integer didn't do the octal detection, it also would have returned the wrong value (2719).

So currently, inifile's attempt to typecast all values into numeric types can cause a number of different issues, especially when the value is a string-that-just-happens-to-only-include-number-characters. It would be good to have a way to turn of typecasting entirely, or determine which are tried.

farski avatar Sep 22 '23 11:09 farski