Double pointers to strings have no NativeTypeInfo

[timsneath]

ShGetKnownFolderPath returns a Pointer<Pointer<Utf16>> in my existing (non-metadata based) projection, but the Win32 metadata shows it as returning a Pointer<Pointer<Uint16>> because there's no NativeTypeInfo attribute for ppszPath.

HRESULT SHGetKnownFolderPath(
  REFKNOWNFOLDERID rfid,
  DWORD            dwFlags,
  HANDLE           hToken,
  PWSTR            *ppszPath
);

ILSpy:

[DllImport("SHELL32", ExactSpelling = true)]
public unsafe static extern HRESULT SHGetKnownFolderPath(
  [In][Const] Guid* rfid, 
  [In] uint dwFlags, 
  [Optional][In] HANDLE hToken, 
  [Out] ushort** ppszPath);

[kennykerr]

It might be better if we added a first-class WCHAR type rather than relying on ushort plus an attribute. That would seem to be a lot simpler given how ubiquitous such pointer types are. Just a thought.

[sotteson1]

I've been thinking the same thing. The problem is not all WCHAR* are null terminated, although most are. And some are double null terminated. We have the same problem with single byte strings too. I could follow our handle pattern for these and use attributes if they're not normal null-terminated strings.

[timsneath]

I suspect we can have our cake and eat it. WCHAR is a good general type for Unicode string types, but we can use attributes to more finely delineate between subtypes.

I'm also wondering (but haven't checked) how we delineate between UTF-8 and ANSI strings, which might both be represented as Pointer<Utf8> in a Dart projection, but are different in that only UTF-8 allows variable length encoding.

[AArnott]

We should not create typedef structs where equivalent ECMA types already exist. We should just use System.Char here.

[AArnott]

Attributes to identify additional traits such as null-termination are fine, but we don't need a custom struct instead of char to represent the data type pointed to.

[kennykerr]

There's a big difference between a char and a LPCWSTR. The latter implies a null terminated string of 16 bit characters. Having a single handle type for LPCWSTR is helpful in avoiding having to always express a pointer to a character that's constant and terminated.

Also, WinRT metadata already reserves ECMA char and string to mean a WinRT character and string respectively. These are different to LPCWSTR and would make it impossible for language projections to deal with both WinRT and Win32 metadata at the same time.

[sotteson1]

I'm suggesting we change strings to look like this:

[NativeTypedef]
public struct PWSTR
{
    public char* Value;
}
 
[NativeTypedef]
public struct PSTR
{
    public byte* Value;
}

And then use attributes for things like const or non-null terminated.

[sotteson1]

Fixed in latest release.