Remove wchar/wstring version of StringPrintf.

Remove wchar/wstring version of StringPrintf.

None of actual usage of StringPrintf(wchar_t*) requires wchar support.
All of them can be replaced by char version of StringPrintf, with
conversion to wstring by ASCIIToWide().

The original intent of this CL is because Android doesn't support wide
characters. But Android suppplies a header wchar.h without a real
implementation, which makes code compile on Android. 4 base_unittests
fail on Android.

BUG=23581
TEST=GeolocationWifiDataProviderCommonTest.MacAddressString

[Hao Zheng, 2012-05-28 13:19:44]

Fixed some clang errors. Now linux and mac trybots are green. win depends on rlz
module, which needs some similar change. I'm on linux now, and I can fix it if
the CL looks favorable. chromeos fails to link my new unittest. I don't know
why, as it compiles on linux and mac.

out/Release/../../third_party/gold/gold64:
out/Release/obj.target/content_unittests/content/browser/geolocation/wifi_data_provider_common_unittest.o:
in function (anonymous
namespace)::GeolocationWifiDataProviderCommonTest_MacAddressString_Test::TestBody():wifi_data_provider_common_unittest.cc(.text._ZN12_GLOBAL__N_159GeolocationWifiDataProviderCommonTest_MacAddressString_Test8TestBodyEv+0x37):
error: undefined reference to 'MacAddressAsString16(unsigned char const*)'
collect2: ld returned 1 exit status
make: *** [out/Release/content_unittests] Error 1

[jar (doing other things), 2012-05-28 16:00:47]

https://chromiumcodereview.appspot.com/10449042/diff/11001/base/stringprintf.cc
File base/stringprintf.cc (right):

https://chromiumcodereview.appspot.com/10449042/diff/11001/base/stringprintf....
base/stringprintf.cc:16: // Overloaded wrapper around vsnprintf. The buf_size
parameter
nit: Comment update: Is this still Overloaded?

[not at google - send to devlin, 2012-05-29 00:08:57]

Hi, what would you like me to review?

[Hao Zheng, 2012-05-29 02:27:05]

Maybe chrome/browser/extensions/ ?
Presubmit check suggested me to add you :)

** Presubmit Messages **
Missing OWNER reviewers for files in these directories:
    ui/gl
    base
    chrome/browser/sync
    content/browser/geolocation

Suggested OWNERS:
    brettw@chromium.org
    apatrick@chromium.org
    kalman@chromium.org


On Tue, May 29, 2012 at 8:08 AM, <kalman@chromium.org> wrote:

> Hi, what would you like me to review?
>
>
http://codereview.chromium.**org/10449042/<http://codereview.chromium.org/104...
>

[not at google - send to devlin, 2012-05-29 02:48:53]

extensions lgtm

However, you shouldn't need OWNERS for chrome/browser/extensions.  I will file a
bug on the presubmit check :)

[Aaron Boodman, 2012-05-29 03:04:58]

On Mon, May 28, 2012 at 7:48 PM,  <kalman@chromium.org> wrote:
> extensions lgtm
>
> However, you shouldn't need OWNERS for chrome/browser/extensions.  I will
> file a
> bug on the presubmit check :)

Why not...? The change modifies chrome/browser/extensions/...

- a

[not at google - send to devlin, 2012-05-29 03:15:36]

On 2012/05/29 03:04:58, Aaron Boodman wrote:
> On Mon, May 28, 2012 at 7:48 PM,  <mailto:kalman@chromium.org> wrote:
> > extensions lgtm
> >
> > However, you shouldn't need OWNERS for chrome/browser/extensions. &nbsp;I
will
> > file a
> > bug on the presubmit check :)
> 
> Why not...? The change modifies chrome/browser/extensions/...
> 
> - a

extension OWNERS doesn't have noparent though.

[Aaron Boodman, 2012-05-29 03:29:14]

On Mon, May 28, 2012 at 8:15 PM,  <kalman@chromium.org> wrote:
> On 2012/05/29 03:04:58, Aaron Boodman wrote:
>>
>> On Mon, May 28, 2012 at 7:48 PM,  <mailto:kalman@chromium.org> wrote:
>> > extensions lgtm
>> >
>> > However, you shouldn't need OWNERS for chrome/browser/extensions.
>> > &nbsp;I
>
> will
>>
>> > file a
>> > bug on the presubmit check :)
>
>
>> Why not...? The change modifies chrome/browser/extensions/...
>
>
>> - a
>
>
> extension OWNERS doesn't have noparent though.

Ah, true, if there's already an LG from someone higher up, this
shouldn't be required.

- a

[Hao Zheng, 2012-05-29 08:48:11]

BTW, rlz CL is at http://codereview.appspot.com/6247057/ .

https://chromiumcodereview.appspot.com/10449042/diff/11001/base/stringprintf.cc
File base/stringprintf.cc (right):

https://chromiumcodereview.appspot.com/10449042/diff/11001/base/stringprintf....
base/stringprintf.cc:16: // Overloaded wrapper around vsnprintf. The buf_size
parameter
On 2012/05/28 16:00:48, jar wrote:
> nit: Comment update: Is this still Overloaded?

Done.

[Evan Martin, 2012-05-29 17:07:28]

perhaps bug=23581

https://code.google.com/p/chromium/issues/detail?id=23581

[Hao Zheng, 2012-05-30 02:49:15]

On 2012/05/29 17:07:28, Evan Martin wrote:
> perhaps bug=23581
> 
> https://code.google.com/p/chromium/issues/detail?id=23581

Done. Thanks for pointing the bug to me.

[brettw, 2012-05-31 23:53:13]

If it's not too out-of-control (I don't actually know how many places it's used)
we're OK with just removing support for the wide version.

[Hao Zheng, 2012-06-01 05:41:08]

On 2012/05/31 23:53:13, brettw wrote:
> If it's not too out-of-control (I don't actually know how many places it's
used)
> we're OK with just removing support for the wide version.

I have changed all places using the wide version in this CL.

[brettw, 2012-06-01 19:27:13]

Just one comment:

https://chromiumcodereview.appspot.com/10449042/diff/11003/base/stringprintf.cc
File base/stringprintf.cc (right):

https://chromiumcodereview.appspot.com/10449042/diff/11003/base/stringprintf....
base/stringprintf.cc:21: inline int vsnprintfT(char* buffer,
I think we can just remove this and call base::vsnprintf. This function was just
to allow both the wchar_t and char versions of the function to be implemented
with an overload.

[Hao Zheng, 2012-06-04 06:35:24]

Reviewers,
Sorry, I have overlooked its use on Windows until trying the Cl on trybot. Did a
grep and found about 60 more uses on Windows only. Most of them are applied to
'%d' or '%x', which could be easily converted to the char version. But there are
still 15 places which look like they need to be wchar* indeed, as they are
dealing with file path, e.g. chrome/installer/util/l10n_string_util.cc.

As Mac/Linux/Android works with the current patch, I'd like to hear your comment
on the following 2 choices:
1. Continue to fix all Windows uses, and replace wide printf with string
concatenation (+)?
2. Make wide printf a Windoes only API?