Here's a patch to make dbg-cli listen on 64 bit linux machines.

In dgbase_globals.h change:



Into this:


Otherwise, the SUCCEEDED and FAILED macros will not function correctly.

Using this I am able to make the client listen and connect. Beyond that I have not used the debugger much so other things could be broken. Just wanted to share it.

-Dave

thanks.
actually simply int would be sufficient.
when I started writing dbg there were no 64bit machines around me and I thought that long will remain 32bit... I was wrong.

the same way, dbgint should be declared as int in dbg_net.h while initially it was long too. I noticed this problem under 64bit Sun ~ 2y ago

as it happens, int would work, because my system happens to have 32 bit ints. But on some 128 bit or more system of the future, int may have more. It's better to be specific and use int32_t. Considering that your macros define HRESULTS to be 32 bit and test for negative values, you have to have exactly 32 bits.




Why doesn't a patch like that make it into the code base?

BTW, I encountered a crash while testing the client on my machine. I submitted a fix here: patch-for-std-sprintf-crash-t1851.html#7118#7118
I don't think its specific to 64 bit machines.[/quote]

Apparently what matters is size of this variable must be identical between client and server. In my case the server was compiled long, so the client must also be compiled long.
I haven't tried recompiling the server, but it sounds like I will have to if I ever want to connect from a 32-bit machine.

Looks like it's time to make changes


Thanks.
It looks a little tricky. Why it does not crash with args copy?

If you don't use a copy of the args, then the second time through that loop, the args structure has been altered by the first loop, and there's no knowing what it now points to. You should be able to reproduce by printing a single variable which is a string of more than 512 chars.

Thanks. Fix will be added to the next free version of the debugger.