https://issues.dlang.org/show_bug.cgi?id=15585

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx
           Severity|normal                      |critical

--- Comment #1 from hsteoh@quickfur.ath.cx ---
Actually, it *does* already cause a very visible, nasty problem:

https://issues.dlang.org/show_bug.cgi?id=15586

Basically, by assuming that dchar can never have invalid values (no matter where the dchar came from), the compiler has basically turned all code containing `cast(dchar)` into undefined behaviour, because it will optimize out all character range checks (under its wrong assumption, none of the checks can ever fail, since dchar can't possibly have invalid values). This means string-vetting functions are basically turned to no-ops, and code that's supposed to throw exceptions or assert errors upon invalid dchar values will instead continue running wildly forward. This could mean that a function that's supposed to return something may actually return nothing, and the caller will get a garbage value instead (from whatever detritus is left in the return register when it was last modified).

These problems are already showing up, even in non-release mode. I'm raising the severity of this bug.

--

https://issues.dlang.org/show_bug.cgi?id=15585

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com

--- Comment #2 from Andrei Alexandrescu <andrei@erdani.com> ---
Thomas, do you have a code sample that illustrates the problem?

--

https://issues.dlang.org/show_bug.cgi?id=15585

--- Comment #3 from thomas.bockman@gmail.com ---
(In reply to Andrei Alexandrescu from comment #2)
> Thomas, do you have a code sample that illustrates the problem?

Sorry; I linked you to this issue by accident. Issue 14835 is the blocker that I mentioned. That said...

bool isValidDChar(dchar cp)
{
    if (cp > dchar.max)
        return false;
    else
        return true;
}

The compiler automatically assumes that (cp <= dchar.max), always. So, *IF* VRP propagated to comparisons, this function would be "optimized" to always return true - which it should not, because it's quite easy to generate dchar values that are greater than dchar.max, even in valid code.

However, VRP isn't currently used for compile-time evaluation of comparisons, so there is (to my knowledge) no way to trigger this issue without my VRP upgrade PR ( https://github.com/dlang/dmd/pull/5229 ).

It's a non-issue; the latest version of that PR already includes the fix for this, so no-one but me should ever be bothered by it, I hope.

--

https://issues.dlang.org/show_bug.cgi?id=15585

--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> ---
great, thx

--

https://issues.dlang.org/show_bug.cgi?id=15585

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--