*.idl: Use correct type for BSTR strings in the defaultvalue() statements.

[Jacek Caban]

On 11/06/15 13:10, Dmitry Timoshkov wrote:
> I don't really follow your objections. It's pretty clear that Wine .idl
> files with defaultvalue("") statements for BSTR type are broken. There
> are two ways to fix them:
> 1) fix .idl files, widl and midl already have proper support for L"" syntax.
> 2) don't fix .idl files (just because PSDK has them that way) and add magic
> handling for BSTR to widl.
> Fixing .idl files is a natural and easy fix, what syntax uses PSDK doesn't
> matter al all, it's even better to differ from PSDK headers in this case.

Well, out of those two options I'd prefer option 1. That's a real bug.
Option 2 just changes IDLs that are perfectly fine, just misinterpreted
by widl.

FWIW think that it's all broken really badly by Microsoft. BSTR strings
are supposed to be allocated by SysAllocString* allocators and can't be
static strings. It will fail as soon as someone tries things like
SysStringLen() call on it. What midl does is promoting broken use of
BSTR type. But, well, we should follow that for compatibility :/

>>>> > > > Generated headers should use L"", like you said. But only in
>>>> > > > case of empty strings.
>>> > >
>>> > > midl always generates L"" syntax, regardless whether it's an empty string
>>> > > or not.
>> > 
>> > 
>> > I don't see this in mshtml.h when default value is not an empty string.
> Probably midl doesn't correctly handle even the magic that it's supposed to
> support. That just confirms that adding "magic" support for defaultvalue()
> to widl wouldn't solve the problem completely, and support for this "magic"
> would need adding even more magic to match midl brokeness.

You both seem to misinterpret what's heppening with mshtm.idl. C++
default values can be emitted only for last arguments. There may be a
few of them, but they can't be followed by an argument without a default
value. That's why midl doesn't emit default values for non-empty strings
found in mshtml.idl. I checked that with tests and midl emits L"..."
strings as expected.

Cheers,
Jacek