Tricky DMD bug, but I have no idea how to report

[H. S. Teoh]

On Wed, Feb 06, 2019 at 09:50:44PM +0000, JN via Digitalmars-d-learn wrote:
> On Tuesday, 18 December 2018 at 22:56:19 UTC, H. S. Teoh wrote:
> > Since no explicit slicing was done, there was no compiler error /
> > warning of any sort, and it wasn't obvious from the code what had
> > happened. By the time doSomething() was called, it was already long
> > past the source of the problem in buggyCode(), and it was almost
> > impossible to trace the problem back to its source.
> > 
> > Theoretically, -dip25 and -dip1000 are supposed to prevent this sort
> > of problem, but I don't know how fully-implemented they are, whether
> > they would catch the specific instance in your code, or whether your
> > code even compiles with these options.
[...]
> No luck. Actually, I avoid in my code pointers in general, I write my
> code very "Java-like" with objects everywhere etc.
[...]

The nasty thing about the implicit static array -> slice conversion is
that your code can have no bare pointers in sight, yet you still end up
with an invalid reference to an out-of-scope local variable.

Some of us have argued that this conversion ought to be be prohibited.
But we haven't actually tried going in that direction yet, because it
*will* break existing code (though IMO such code is suspect to begin
with, and besides, all you have to do is to explicitly slice the static
array to get around the newly-introduced compile error).

Of course, I've no clue whether this is the cause of your problems --
it's just one of many possibilities.  Pointer bugs are nasty things to
debug, regardless of whether or not they've been abstracted away in
nicer clothing.  I still remember pointer bugs that took literally
months just to get a clue on, because it was nigh impossible to track
down where they happened -- the symptoms are too far removed from the
cause.  You pretty much have to take a wild guess and get lucky.

They are just as bad as race condition bugs. (Once, a race condition bug
took me almost half a year to fix, because it only showed up in the
customer's live environment and we could never reproduce it locally. We
knew there was a race somewhere, but it was impossible to locate it.
Eventually, by pure accident, an unrelated code change subtly altered
the timings of certain things that made the bug more likely to manifest
under certain conditions -- and only then were we finally able to
reliably reproduce the problem and track down its root cause.)


T

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but
haven't gotten around to it yet. " -- swr