Bug 11910 – Writes to extern (C) struct have no effect

Is this bad codegen, or have I done something wrong? extern (C) struct MFDefaults { extern (C) struct InputDefaults { bool allowMultipleMice; bool mouseZeroIsSystemMouse; bool systemMouseUseWindowsCursor; bool useDirectInputKeyboard; bool useXInput; } InputDefaults input; } extern (C) __gshared MFDefaults gDefaults; void f() { gDefaults.input.useXInput = false; // assignment has no effect } This code builds and links successfully. In the debugger I can inspect the values of the struct and they are correct, consistent with the struct in the C code. But when I assign to anything, it simply has no effect...

I checked the generated code on Linux x86_64 and it seems fine (store immediate zero in gDefaults at offset 4). So, more details and instructions to reproduce, please. ;)

I'm building with DMD-Win64. Digging further, I see this instruction in the debugger: mov byte ptr [gDefaults+9Ch (7F685FBF01Ch)],1 Which looks correct... But note, the debugger helpfully shows the calculated store address: 7F685FBF01Ch &gDefaults.input.useXInput == 7F685FEBC7Ch It should write to ...FEBC7Ch, but instead it writes to ...FBF01Ch, which is WAY before where it should be writing. If I inspect the memory surrounding the address that it actually writes to, it is filled with things like fully justified D symbols (with module name and everything), path strings, lots of zeroes and float 1.0's. Not the structure I expect to see.

(In reply to comment #2) > I'm building with DMD-Win64. > > Digging further, I see this instruction in the debugger: > mov byte ptr [gDefaults+9Ch (7F685FBF01Ch)],1 Note: +9C in mine is because my structure is actually much larger, I trimmed it down to log the bug. The offset 9C looks right. The debugger also illustrated 'gDefaults' as the store address, which I guess means the address it writes to does match the symbol record in the debug info. I guess the address emitted for gDefaults is wrong somehow? But... that symbol should come from the external C library :/

(In reply to comment #3) > Note: +9C in mine is because my structure is actually much larger, I trimmed it > down to log the bug. The offset 9C looks right. > > The debugger also illustrated 'gDefaults' as the store address, which I guess > means the address it writes to does match the symbol record in the debug info. > I guess the address emitted for gDefaults is wrong somehow? > But... that symbol should come from the external C library :/ What is "gDefaults" supposed to be? A symbol from a C library? In that case you forgot "extern", the correct declaration should be: extern (C) extern __gshared MFDefaults gDefaults; Have a look at: http://dlang.org/interfaceToC.html#C%20Globals

(In reply to comment #4) > > What is "gDefaults" supposed to be? A symbol from a C library? Yes, I thought that was clear from the 'extern (C)'. > In that case you forgot "extern", the correct declaration should be: > > extern (C) extern __gshared MFDefaults gDefaults; Umm... I think you need to look at the OP again.

(In reply to comment #4) > > In that case you forgot "extern", the correct declaration should be: > > extern (C) extern __gshared MFDefaults gDefaults; > > Have a look at: http://dlang.org/interfaceToC.html#C%20Globals ... oh Crap, where's that edit button! Wow, I have no words. I never would have spotted that a mile off, even when you said it! That seems extremely redundant :/

(In reply to comment #6) > ... oh > Crap, where's that edit button! > > Wow, I have no words. > I never would have spotted that a mile off, even when you said it! > > That seems extremely redundant :/ If you don't specify "extern" you get the storage of the variable in the D code.

(In reply to comment #7) > If you don't specify "extern" you get the storage of the variable in the D > code. Right, but shouldn't I have gotten a multiply defined symbols link error in that case? * Marked resolved, user error! >_<

(In reply to comment #8) > Right, but shouldn't I have gotten a multiply defined symbols link error in > that case? I think in some cases it just overrides the C symbol. Not overrides, but prefers the one in D. Walter has mentioned a couple of times this is possible. It might be a Windows/Optlink only thing.

(In reply to comment #9) > (In reply to comment #8) > > > Right, but shouldn't I have gotten a multiply defined symbols link error in > > that case? > > I think in some cases it just overrides the C symbol. Not overrides, but > prefers the one in D. Walter has mentioned a couple of times this is possible. > It might be a Windows/Optlink only thing. I'm linking against C code, so I have to use Win64 and the MS linker, which I'm very familiar with. It may be that it just chose one, but curious to know why... anyway, all good. I'll look into that more closely later on. False alarm, thanks for spotting my mistake! >_<

(In reply to comment #10) > I'm linking against C code, so I have to use Win64 and the MS linker, which I'm > very familiar with. > It may be that it just chose one, but curious to know why... anyway, all good. I found this on stackoverflow[1]: "The linker will search the files you provide on the command line first for symbols, before it searches in libraries" [1] http://stackoverflow.com/a/19023148/1787929