512700 - String::containsLatin1 comparison fails on windows for characters > 0x7F

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Jerry Hall]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: AVMPLUS 1.4 2007-04-01/2009-04-24

I was calling String::containsLatin1("\xAD") to find out if a string contained a soft-hyphen character, but on Windows this function fails if the underlying string is represented by an 8-bit buffer. The failure occurs on line 764 of StringObject.cpp:

                                        if (selfBuf.p8[j] != p[j])
                                                break;

because elements of "p8" are of type "unsigned char" and elements of "p" are of type "char". On Windows "char" is a signed type so this code becomes a signed/unsigned comparison. I believe in this case that the compiler will promote each side to "int" and because value preserving rules the negative number will be sign extended and will never compare equal. Simply casting "p[j]" to "uint8_t" fixes the problem.

Note: there may be other instances of this kind of bug in the String class, e.g. String::indexOfLatin1 or String::matchesLatin1.

Reproducible: Always

Steps to Reproduce:
1. Create string with content: "ev-i-dent" where hyphen character is a soft hyphen: 0xAD
2. Call containsLatin1("\xAD") on string

Actual Results:  
Step 2 returns false on windows. Other platforms where type char is signed will also exhibit this behavior.

Expected Results:  
Step 2 should return true.

Comment 1

[Steven Johnson]

Nice catch. I'll add appropriate testcases along with the fix.

Comment 2

[Steven Johnson]

Attachment: Patch

Fixes the bug. 

Also adds selftests for the relevant String apis (and fixes some minor issues with compiling in selftest mode under Xcode.)

Comment 3

[Steven Johnson]

pushed fix to redux as changeset:   2409:b0fb0a8a6bf4