Posted here as this appears to be a Win64 issue only.
follow up to this post:
32/64 bit issue
The code compiles and runs fine on gcc/g++ 4.8.2 on 64 bit Linux Mint 17 and OpenSuSE 13.1 Linux (g++ 4.8.1) 32 and 64 bit .
James
Posted here as this appears to be a Win64 issue only.
follow up to this post:
32/64 bit issue
The code compiles and runs fine on gcc/g++ 4.8.2 on 64 bit Linux Mint 17 and OpenSuSE 13.1 Linux (g++ 4.8.1) 32 and 64 bit .
James
Look closely at all the hard-coded (literal) values. It is likely some of those reflect an assumption about the size of some type.
Also look closely at every point where sizeof() has been used. It is fairly obvious, even on a casual look, that the "update" to go from 32 to 64 bit converted some literal values representing (assumed) sizes of types to expressions in terms of sizeof(). If even one of those changes was careless (and looking at the organic nature of the code, I'd bet that is the case) it would explain your problem.
Either of the above are particularly likely the culprit given that the code manipulates void pointers all over the place. It is also likely there are multiple such errors.
Assumptions to look out for, as any may be wrong.
1) An integral type is a particular size (2,4,....)
2) A pointer type is a particular size (4,8, .....)
3) Two different pointer types are the same size (admittedly, this assumption is likely to be true in practice)
4) Some integral type and some pointer type are the same size.
Another thing to look for (as Salem pointed out in the other thread) is that the code is doing bit fiddling with signed ints. Bit fiddling with signed integral types has undefined (at best, unspecified) results if any of the values being fiddled are negative.
This isn't a win64 issue though. You're just getting lucky that the embedded assumptions happen to work on compilers where they work. Such is the case when in the realm of implementation-defined behaviour.
grumpy,
As a well respected contributer to this site I want to thank you for examining the code and providing
your direction insights. Unfortunatly the code is not mine and as a still novice,aging c/c++ coder just following it is a bit of a chore.
In my research I did find many articles and forum discussions about the 64 bit implementation of Variable Argument Lists.
My head scratching comes about by the apparent success of gcc/g++ on Linux64 and Tiny-C 64 on Windows.
Thanks again,
James
Where does it crash?
I highly recommend running the program in valgrind, it'll let you know if your program is writing/reading/allocation/freeing memory it shouldn't be; it even tells you about reading uninitialized memory.
As Salem & grumpy point out, messing with signed variable bits is dangerous, but gcc with the -Wall flag should tell you where you're doing this, so it should be an easy fix. It's also best to always compile with -Werror when finalizing your program.
Yarin,
Last I knew valgrind was linux only.
If you had read my last post a little more carefully you would notice there is NO problem on Linux.
James
This had escaped me....Originally Posted by jcfuller
Well, you could compile the program for Windows as usual, then run it through Wine, through valgrind.
Or, you could try Dr. Memory. I haven't tried it, but it appears to fit the bill, and is available for Windows.
EDIT: Sorry looks like Dr. Memory is 32-only. :l You could still try Wine/valgrind.
Last edited by Yarin; 10-10-2014 at 10:12 AM.
It's the recursion that is killing it with 64 bit MinGW gcc,VC++
It's all handle with built in functions instead of macros.
TinyC 64 copies all the registers to the stack and uses basically the same macros as 32bit
The 64bit Linux gcc and the 64bit MinGW gcc handle it differently.
MinGW gcc, I assume, follows the VC++ way and as is often the case it was butchered
Some insight:
https://blog.nelhage.com/2010/10/amd64-and-va_arg/
James
This turned out to be a DUH, and really a non va_list issue.
The original basic source was doing a REDIM PRESERVE on an empty array so there was nothing to preserve.
If the same code uses just REDIM or the arrays contain data all is well!
Now I guess the question is why does it work on 32bit ?
The algorithm or translator needs to be aware of an empty array and flag it as an error.
Again, Thank you all for your time on this matter.
James
Forgive me if I don't seem surprised.
That's probably just a sign of using realloc() on an uninitialised pointer. It working with one target but not another is just par for the course with undefined behaviour.
Or handle the reallocation safely.
