WTF is going on! Corrupt value that is never assigned

[Moritz Maxeiner via Digitalmars-d-learn]

On Thursday, 13 July 2017 at 22:53:45 UTC, FoxyBrown wrote:
> On Thursday, 13 July 2017 at 20:35:19 UTC, Moritz Maxeiner 
> wrote:
>> On Thursday, 13 July 2017 at 18:22:34 UTC, FoxyBrown wrote:
>>> The following code is pretty screwed up, even though it 
>>> doesn't look like it. I have a buf, a simple malloc which 
>>> hold the results of a win32 call. I am then trying to copy 
>>> over the data in buf to a D struct.
>>>
>>> But when copying the strings, the buf location changes, 
>>> screwing up the copying process. It shouldn't happen, buf 
>>> never changes value anywhere except the first malloc(which is 
>>> once). Somehow it is getting changed, but where?
>>>
>>> [...]
>>>
>>> The buf value changes when calling cstr2dstr but I've had it 
>>> with other values to(any function call such as to!string, etc 
>>> seems to trigger it).
>>>
>>> [...]
>>
>> - Does this happen every time, or only sometimes?
> yes, but I've been having this problem and not sure if it was 
> quite as consistent as before or that I just recognized it.
>
>> - At which loop iteration does it occur?
> Now it seems to occur after the first iteration, but I've add 
> it happen after a while and in other cases it's worked.. 
> depends on if I use malloc, or a D array, or what.
>
>> - Which compiler (+version) are you using (with what flags)?
> Latest DMD official.. whatever default flags exist in debug 
> mode with visual D... why should it matter? [...]

Because it's part of the usual "Steps to reproduce" you are 
supposed to provide so others can verify what you're encountering.

>> - What are the steps to reproduce (i.e. does this e.g. happen 
>> with a main that consist of one call to EnumServices) ?
>
>
> Yes, It is basically the first thing I do when I run my 
> program. [...]

Okay, I'll setup a Windows VM when I have time and check it out 
(unless someone solves it beforehand).

> because D  is not interfacing well with C. First, the win32 
> function  does not simply fill in an array but adds additional 
> junk at the end(didn't know that until after a few wasted hours 
> trying to get it to fill in an array properly).

To be fair, that's neither C nor D fault; that's Microsoft 
providing unintuitive, horrible APIs and doing an amazing job of 
providing documentation (MSDN) that *appears* to be exhaustive 
and well written, but misses all these little important details 
that you actually have to know in order to program correct 
control logic, driving you to the edge of sanity. Been there, 
done that.

> I don't know how any stack corruption could be occurring but 
> that is exactly what it looks like. "Return from function call 
> and "static variables"(with respect to the call) are changed.". 
> But that seems really hard to sell given that it's pretty 
> simple and D should have all those basics well covered.

It's always possible for the D compiler to generate wrong code 
(though I'm not convinced that this is the case here), you should 
have a look at the generated assembly.