date_time exceeds array bounds in special_value_from_string

[Brad Spencer <spencer@…>]

gcc-4.3.2 found this with its new -Warray-bounds feature. It took a few minutes to track down even with the compiler pointing in the right direction:

In ​https://svn.boost.org/trac/boost/browser/trunk/libs/date_time/src/gregorian/greg_month.cpp#L76 an array called special_value_names (defined in ​https://svn.boost.org/trac/boost/browser/trunk/libs/date_time/src/gregorian/greg_names.hpp#L22 ) is passed into the function find_match() as array to search.

The enumeration constant date_time::NumSpecialValues (defined in ​https://svn.boost.org/trac/boost/browser/trunk/boost/date_time/special_defs.hpp#L15 ) is passed to find_match() as the "limit" argument.

The find_match() function (defined in ​https://svn.boost.org/trac/boost/browser/trunk/boost/date_time/date_parsing.hpp#L76 ) uses "limit" as an "up to and including" bounds on its for() loop for iterating over the array(s).

However, the NumSpecialValues enumeration member has a value of 6 (it follows the 6 valid enum values), and the special_value_names contains only 6 strings (corresponding to those 6 valid enum values). Because find_match() goes "up to and including" its limit, in this instance it can go off the end of the special_value_names array.

The documentation on find_match() is ambiguous as to whether or not the "limit" index itself is intended to be referenced, but it is very explicit that date_time::NumSpecialValues is supposed to be a valid argument for limit. This would seem to imply that the for() loop condition is wrong, except that all the other uses of find_match() use a constrained_value with a max() value that is the maximum desired value.

I think the best conclusion here is that passing a "count"-type value (NumSpecialValues) for a "max"-type value (the more ambiguously named "limit") is incorrect. Thus, the attached patch.

[Andrey Semashev]

Fixed in revision: 49875