Add windows-specific result files for form_combobox_num/per tests.

Add windows-specific result files for form_combobox_num/per tests.

The output from these clever tests depends upon the platform-specific
behaviour of fcvt() when more significant digits are requested
than there is precision in a double type.

TBR=thestig@chromium.org

Committed: e733fe1d98fad50c9b5f4023f08db429143b1291

[Tom Sepez, 2015-04-08 21:52:28]

tsepez@chromium.org changed reviewers:
+ thestig@chromium.org

[Tom Sepez, 2015-04-08 21:53:30]

TBD'd.  We'll use these in a follow-up CL to enable per-platform expected
results files.

[Tom Sepez, 2015-04-08 22:22:41]

Committed patchset #1 (id:1) manually as
e733fe1d98fad50c9b5f4023f08db429143b1291 (presubmit successful).

[Tom Sepez, 2015-04-09 16:33:01]

+Bruce (you'll enjoy this one)

[brucedawson, 2015-04-09 16:49:16]

Uggh. And in addition to the differences in printing doubles there is also the
risk that different platforms could generate different doubles, given the
not-completely-precise specification of floating-point math.

BTW, VS 2015 changes how it deals with excess digit requests. VS 2013 and
earlier will print zeros after the 17th mantissa digit. VS 2015 will actually do
the right thing and print as many digits as requested, which can be hundreds of
non-zero digits (17 digits uniquely identifies a double, but a double still has
a specific value which may requires hundreds of digits to represent)

[Lei Zhang, 2015-04-09 19:29:03]

lgtm

Should we file a bug for this platform inconsistency and fix it at some point?

[Tom Sepez, 2015-04-09 19:33:15]

On 2015/04/09 19:29:03, Lei Zhang wrote:
> lgtm
> 
> Should we file a bug for this platform inconsistency and fix it at some point?

https://code.google.com/p/pdfium/issues/detail?id=138

[Lei Zhang, 2015-04-22 00:53:51]

BTW, this got committed with the author as "unknown <tsepez@chromium.org>"