cast(wstring)entry.szExeFile == Name
to!wstring(entry.szExeFile) == Name

These all fail. The strings are clearly the same. I can compare char by char and it works. latest D 2.088. The only thing is that szExeFile is a static wchar array... which shouldn't effect the comparison.

On Monday, 23 September 2019 at 20:38:03 UTC, Brett wrote:
> cast(wstring)entry.szExeFile == Name
> to!wstring(entry.szExeFile) == Name
>
> These all fail. The strings are clearly the same. I can compare char by char and it works. latest D 2.088. The only thing is that szExeFile is a static wchar array... which shouldn't effect the comparison.

If you're comparing a static array, you're also comparing the bytes after the NUL character. Both of those conversions will give you a wstring with the length of the entire array, regardless of and including any NUL characters, so that's probably not what you want. fromStringz would probably be more appropriate there.

On Mon, Sep 23, 2019 at 08:38:03PM +0000, Brett via Digitalmars-d-learn wrote:
> The only thing is that szExeFile is a static
> wchar array... which shouldn't effect the comparison.

are you sure about that?

with a static size, the lengths of the two sides won't match...

On Monday, 23 September 2019 at 20:45:00 UTC, destructionator wrote:
> On Mon, Sep 23, 2019 at 08:38:03PM +0000, Brett via Digitalmars-d-learn wrote:
>> The only thing is that szExeFile is a static
>> wchar array... which shouldn't effect the comparison.
>
> are you sure about that?
>
> with a static size, the lengths of the two sides won't match...

I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match...

...rather than failing silently.

On Monday, September 23, 2019 5:22:14 PM MDT Brett via Digitalmars-d-learn wrote:
> On Monday, 23 September 2019 at 20:45:00 UTC, destructionator
>
> wrote:
> > On Mon, Sep 23, 2019 at 08:38:03PM +0000, Brett via
> >
> > Digitalmars-d-learn wrote:
> >> The only thing is that szExeFile is a static
> >> wchar array... which shouldn't effect the comparison.
> >
> > are you sure about that?
> >
> > with a static size, the lengths of the two sides won't match...
>
> I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match...
>
> ...rather than failing silently.

D does virtually nothing with null terminators. String literals have them one index past their end so that you can pass them to C functions without D code actually seeing the null terminator, but otherwise, you have to add the null terminator when passing to C code (e.g. with toStringz or toUTFz), and you have to strip it off when getting a string from C code (e.g. with fromStringz). Other than functions specifically designed to convert to and from C strings, D code is going to treat null terminators just like any other character, because D strings are not null-terminated.

- Jonathan M Davis

On Monday, 23 September 2019 at 23:22:14 UTC, Brett wrote:
> I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match...
>
> ...rather than failing silently.

It might still be useful for generic code, so a compiler warning would probably not be suitable. However, it might be a good idea for a linter such as Dscanner, which, unlike the compiler, sees types as they are written in the code, not as they are calculated through metaprogramming.

On Tuesday, 24 September 2019 at 00:29:05 UTC, Vladimir Panteleev wrote:
> On Monday, 23 September 2019 at 23:22:14 UTC, Brett wrote:
>> I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match...
>>
>> ...rather than failing silently.
>
> It might still be useful for generic code, so a compiler warning would probably not be suitable. However, it might be a good idea for a linter such as Dscanner, which, unlike the compiler, sees types as they are written in the code, not as they are calculated through metaprogramming.

The only issue is that buggy dynamic code can result if someone compares the two and it will fail silently. It could be quite complex bug that destroys the space station.  Warnings never hurt and with the ability to disable specific ones one can bypass such issues. (disable then enable)

But if it behaves in a non-standard way based on some somewhat arbitrary limitation(fixed arrays are only arbitrary because of the limitations of computers) then it's going to bit people and the more D is used the more people that will get bitten.

If I convert a static array to a string, I want the "string" portion of the array. Strings are special, they are meant to have specific representation. Strings do not have 0 characters in them normally.

So upon conversion, to!string would detect this and either error out or stop the conversion at that point. The only time one would want to retain junk values is for displaying bytes, but then one should just convert to a byte or char array.

But of course those people that have be using to!string to convert arbitrary bytes will have their code broken... but I imagine few have done this(there really is no point).

The same thing should happen when converting anything to a string, it should detect malformed strings and either error or terminate(if zero terminated).

This makes for a more consistent ecosystem.

if, for example, I stick null terminated strings in a buffer then to!string will automatically recover them(the first one, assuming one each time).

There is probably no win-win situation though and so I suggest just a warning when converting arrays to strings.

On Tuesday, 24 September 2019 at 21:40:47 UTC, Brett wrote:
> The only issue is that buggy dynamic code can result if someone compares the two and it will fail silently.

But, you don't know if the static array actually contains a null-terminated string (in which case the comparison is a bug) or an actual meaningful string of that length, such as a string literal represented as a static array (in which case the comparison is completely valid).

> It could be quite complex bug that destroys the space station.

The worst kind of bugs are the ones for which the program works correctly 99.9% of the time (including in all unit tests), but 0.1% of the time things explode. This doesn't seem to me like that kind of a bug, if only that a NUL character will always be presented in a zero-terminated string embedded in a static array, but practically never in a D string.

> If I convert a static array to a string, I want the "string" portion of the array.

Zero-terminated strings are kind of a C thing. D isn't C, it has its own string type. Even though many libraries use a C ABI for interop, and thus use C strings, this isn't a requirement for a D program - after all, you can write your own kernel and operating system in D, all fully without zero-terminated strings.