Integer overflow in Calc lcl_getSingleCellAddressFromXMLString nColumn computation

[Stephan Bergmann]

On 23/02/2021 11:08, Stephan Bergmann wrote:
> On 23/02/2021 08:34, Stephan Bergmann wrote:
>> I have no idea whether lcl_getSingleCellAddressFromXMLString is 
>> legitimately getting called here with those arguments (or if the real 
>> error is somewhere else), what that nColumn computation actually 
>> means, nor what's going on in general.  If anybody knowledgeable about 
>> that code could please have a look.
> 
> With a little more digging:  However sc/qa/uitest/data/tdf107097.ods was 
> generated, its "Object 1/content.xml" sub-file contains the XML element
> 
>> <chart:plot-area chart:style-name="ch3" 
>> table:cell-range-address="PivotChart" 
>> chart:data-source-has-labels="column" svg:x="0.398cm" svg:y="0.991cm" 
>> svg:width="16.013cm" svg:height="9.381cm">
> 
> whose table:cell-range-address attribute appears to what gets processed 
> here.

On recent master, if I create a bare-bones pivot.ods containing a pivot 
chart (in a fresh Calc document, type "A" into A1 and "2" into A2, click 
into A1, then "Insert - Pivot Table... - OK" and drag "A" from 
"Available Fields" to "Column Fields" and "OK", then "Insert - Chart... 
- Finish", then save):  The resulting pivot.ods "Object 1/content.xml" 
sub-file contains a chart:plot-area XML element with a 
table:cell-range-address="PivotChart" attribute as above, but which 
appears to be nonsense according to the ODF standard as quoted below.

Maybe some Calc expert can shed some light on what is going on here, and 
if that

   <chart:plot-area table:cell-range-address="PivotChart" ...>

is legitimate, and should legitimately be processed with 
lcl_getSingleCellAddressFromXMLString as is done here.

> Now, 
> <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1418304_253892949> 
> "19.593.6<chart:plot-area> (deprecated)" specifies that that attribute 
> shall be of type 
> <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#datatype-cellRangeAddressList> 
> "18.3.6cellRangeAddressList" aka 
> <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#CellRangeAddressList> 
> "9.2.5Cell Range Address List".  Lacking whitespace, "PivotChart" is 
> apparently a list containing a single cell range addresses or cell 
> addresses, and lacking a colon, it apparently is a cell address.
> 
> <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415614_253892949> 
> "Referencing Table Cells" specifies the structure of such a cell address:
> 
>> Cell addresses are constructed as follows:
>>
>>     1)The name of the table.
>>     2)A dot “.” (U+002E, FULL STOP).
>>     3)An alphabetic value representing the column. The letter A 
>> represents column 1, B represents column 2, and so on. AA represents 
>> column 27, AB represents column 28, and so on.
>>     4)A numeric value representing the row. The number 1 represents 
>> the first row, the number 2 represents the second row, and so on.
> 
> But lcl_getCellAddressFromXMLString and 
> lcl_getSingleCellAddressFromXMLString in 
> chart2/source/tools/XMLRangeHelper.cxx apparently attempt to parse 
> something rather different:
> 
> * lcl_getCellAddressFromXMLString supports backslash quoting;
> 
> * lcl_getCellAddressFromXMLString makes the leading table name and dot 
> optional;
> 
> * lcl_getSingleCellAddressFromXMLString supports an optional "$";
> 
> * lcl_getSingleCellAddressFromXMLString supports lower-case letters in 
> addition to upper-case letters for the column;
> 
> * lcl_getSingleCellAddressFromXMLString makes the numeric value 
> representing the row optional.
> 
> I'm still not sure what to make of all that.  Is 
> sc/qa/uitest/data/tdf107097.ods bogus and should be rejected?  Xisco, 
> can you please clarify how you created that file?  Should the parsing 
> code in chart2/source/tools/XMLRangeHelper.cxx be less lenient and 
> reject that "PivotChart" value (or is that parsing code also used in 
> situations that ask for parsing another grammar)?