Leftovers from wstring->string16 conversion in authentication code.

Leftovers from wstring->string16 conversion in authentication code.

I'm really confused how this even compiled in the first case (such as the npos comparison).

BUG=50517
TEST=net_unittests, tested on Ubuntu against NTLM server + proxy.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=55109

[cbentzel, 2010-08-05 18:24:29]

Oh, yeah, npos is just a size_t.

Anyway, I'm now confused why the find was able to compile, and what
automatic-conversions are happening (if any)

[Lei Zhang, 2010-08-05 18:45:37]

LGTM

I too am surprised that code compiled.

[cbentzel, 2010-08-05 18:50:49]

Yeah. I'm going to spend a tiny bit of time figuring it out as it likely led
to the crash reported in the bug (which started the same day you landed this
wstring->string16 change and at the same line of code). I'm worried there's
other lurking bugs as part of the conversion.

On Thu, Aug 5, 2010 at 2:45 PM, <thestig@chromium.org> wrote:

> LGTM
>
> I too am surprised that code compiled.
>
>
> http://codereview.chromium.org/2808107/show
>

[cbentzel, 2010-08-05 21:33:26]

The original disassembly at the call site (in debug build) was 

41	  size_t backslash_idx = username->find(L'\\');
   0x00007ffff656f5d2 <+90>:	mov    -0x3b0(%rbp),%rax
   0x00007ffff656f5d9 <+97>:	mov    $0x0,%edx
   0x00007ffff656f5de <+102>:	mov    $0x5c,%esi
   0x00007ffff656f5e3 <+107>:	mov    %rax,%rdi
=> 0x00007ffff656f5e6 <+110>:	callq  0x7ffff67474d0
<_ZNKSbItN4base20string16_char_traitsESaItEE4findEtm@plt>
   0x00007ffff656f5eb <+115>:	mov    %rax,-0x68(%rbp)

The mov $0x5c,%esi line is where the wchar_t literal L'\\' is copied to a
register. Maybe this is a conversion case where it knows the upper 16-bits are 0
(and actually, the upper 24-bits are 0) so this is acceptable.