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.
