Question about xmrig source code, is it bug in source? about xmrig

[SChernykh]

Did you try to compile with #3461? Like I said, I can't reproduce your results.

Edit: it is, indeed, 16 bytes in g++. I'll look into it.

[SChernykh]

#3462 should fix it.

[SChernykh]

sizeof(p) is 8, and your code prints sizeof(p) 8 sizeof(engine)/256 8 when I compile it in MSVC. What compiler version did you use? Maybe you used some special compiler settings?

[SChernykh]

In any case, this PR should make this a compile-time problem instead: #3461
If it compiles, you can be sure pointer sizes match.

[xcryptodigger]

sizeof(p) is 8, and your code prints sizeof(p) 8 sizeof(engine)/256 8 when I compile it in MSVC. What compiler version did you use? Maybe you used some special compiler settings?

It is not only on MSVC.
When built on Ubuntu, g++ then it prints
sizeof(p) 16 sizeof(engine)/256 8
So it is also not correct and again memcpy spoils memory after engine array.

I noticed that because when my own JIT compiler implementation grows with code then sometimes it works and sometimes does not work just because unpredictable behave. And seem reason is those handler pointers.

[xcryptodigger]

Thank You!
Seems now fixed.
PS: Someone can explain why compilers can reserve too much bytes per simple pointer? I have no idea why..

[SChernykh]

I found this article on the topic: https://devblogs.microsoft.com/oldnewthing/20040209-00/?p=40713