To the devs,
I've just been playing around with the source in an archaic cross-compile environment and it turns out that my compiler/libraries do not like to free NULL pointers.
I've started a find/replace to replace any calls to free to my own safe_free which checks for a NULL pointer first.
Would this change be acceptable in the trunk? I would be angry if I had to start using safe_free instead of free.. but for this current port it is the easiest method to get around the current problem; unless someone knows how to inline a free() func that has the same name as the free() func that you then want to call
stevenh wrote:unless someone knows how to inline a free() func that has the same name as the free() func that you then want to call
I guess your archaic environment doesn't support dynamic linking, does it? Otherwise, you could maybe provide your own implementation before the default libc (or however this is called in your environment) is loaded. E.g. on Linux this is used by memory leak checkers (LD_PRELOAD is the keyword here).
You may also just try to provide your own free implementation and hope that it does not try to take the one from the libraries then. However, I don't see how you could access the original implementation then. And writing your own memory management is probably nothing you would like to do
As an easy but dirty solution you could try this line in a header that is included anywhere you use free:
I was just about to write "Isn't that classed as an infinite loop...." until I realised that the definition of the new 'free' is after the usage of the old 'free'....
Quite interesting... I might just do this... Thank all...
Now to work out endian issues... opntitle.dat wont work unless I have TO_LE32X in the Savegame formats which means that the 'direct' hdr[0] Uint32 that it's pulling out is being read in the "wrong" direction...
About the free stuff: At least the Atari ST did not supported free(0), since the runtime (like many other too) give it to the OS free, which choked on it.
Aparently there are different interpretations of K&R delete NULL around too: I know of at least three compiler/development systems, where this would cause a warning or a breakpoint. (Albeit nothing that cannot be fixed by a define ... )
By the way, I think here is a confusion between K&R and ANSI. PDP-7 C (which was directly from K&R more or less) did not allowed free(NULL), it caused an error. At least it did when I did my first EDV courses.
I like to look at great maps and see how things flow. A little like a finished model railway, but it is evolving and actually never finished. http://www.simutrans.com
Loading of opntitle.dat currently works fine both on big endian and little endian machines. Most likely the target endian was not detected correctly. You can use the --endian configure parameter to override this.
A small update.... using peter1138's code worked until I attempted to flip endians and recompile everything... aystar.cpp uses a class function 'free' and seems to get this confused with the #define. This makes no sense to me, as the 'free' inside the class should not be overriden... for now I've renamed the class function.
Secondly... it seems that the libraries I am using for my system bring the CPU up as big-endian but the application that creates the romdisk writes the files as little endian... I reversed the readbyte functions in saveload.cpp, but things still seem a little weird... I'll screw around with it more once I get the time.
stevenh wrote:A small update.... using peter1138's code worked until I attempted to flip endians and recompile everything... aystar.cpp uses a class function 'free' and seems to get this confused with the #define. This makes no sense to me, as the 'free' inside the class should not be overriden... for now I've renamed the class function.
That's why it is called a preprocessor. Preprocessor macros are substituted before the "real" compiling stage and thus ignore scoping completely and replace everything that matches. That is why you should avoid using preprocessor macros in C++ wherever possible (i.e. using inline functions or constants). Unfortunately, AFAICS this is one of the rare cases where there is no other way than using preprocessor macros. It's a hack anyway, so renaming the member function seems to be the best you can do about it.
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
stevenh wrote:A small update.... using peter1138's code worked until I attempted to flip endians and recompile everything... aystar.cpp uses a class function 'free' and seems to get this confused with the #define. This makes no sense to me, as the 'free' inside the class should not be overriden... for now I've renamed the class function.
That's why it is called a preprocessor. Preprocessor macros are substituted before the "real" compiling stage and thus ignore scoping completely and replace everything that matches. That is why you should avoid using preprocessor macros in C++ wherever possible (i.e. using inline functions or constants). Unfortunately, AFAICS this is one of the rare cases where there is no other way than using preprocessor macros. It's a hack anyway, so renaming the member function seems to be the best you can do about it.
Rainer wrote:
perhaps a little #undef will do it...
That would soon going to get ugly as not only the definition of this free member is the problem. The calls to the member are problematic as well. You would have to be really careful where the #define should be in effect an where not. I think renaming is the cleaner solution (esp. easier to maintain).
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
