Reply to Re: GNU Freedink - New Maintainer
If you don't have an account, just leave the password field blank.
Alright @kjh, so here is my BIG comprehensive list of misused longs in freedink, i think it covers everything:
----------- Critical misuse of long ----
As discovered by ghostknight, these are gamebreaking in certain scenarios and need to be int.
----------- Probably has no impact ----
----------- Timing variables, need to be Uint32, possible issues? ----
All of these instances are linked to variables that are used for timing / game tick management. I *THINK* they are supposed to be Uint32 and NOT Int32, it probably doesn't matter if they are 64 bit, but it can cause issues if compiled for x86 with 32 bit longs i think?...
I say they should be Uint32, because they are used in relation to variables which are indeed declared as Uint32
IMPORTANT NOTE: Robj, please correct me if timer overflow from 2147483647 to -2147483648 is ever used in magic DMOD trickery. I expect it shouldn't though, and letting timers run from 0 to 4294967296 should be fine?...
Variable cycle_clock:
Variable mold:
Struct sp in live_sprite.h
----------- Used in file access, needs to be AT LEAST 32 bit ---
None of the dink files can ever reach sizes ranging in the GB, so 32 bits are more than enough for file access.
Variables of the struct refinfo, these all are used in file access, need to be at least Int32, but 64 bit not ever needed
These variables seem to be used in fseek, so technically it is not wrong for them to be "long", however, no map.dat file will ever be big enough to require long, so i think they should be changed for consistency anyway
These variables are used to refer to some file offsets in the dir.ff files. As far as i am aware, dir.ff files use 32 bit when storing offsets internally, so these should be Int32 as well...
----------- Critical misuse of long ----
As discovered by ghostknight, these are gamebreaking in certain scenarios and need to be int.
// dinkc.cpp, line 51: /* store current procedure arguments expanded values of type 'int' (see get_parms) */ static long nlist[10]; // dinkc.cpp, line 1748: // here there is a size mismatch between declaration and memset use memset(nlist, 0, 10 * sizeof (int)); // dinkc.cpp, line 603 // this function stores its return value in nlist, it should also be int long decipher(char* variable, int script) // dinkc.h, line 116 extern long decipher(char* variable, int script);
----------- Probably has no impact ----
//dinkc.cpp, line 72 //in the call_back struct, the min/max variables are long when //they should be int, they are only used in combination with other ints struct call_back { int owner; // script ID /*bool*/int active; int type; char name[20]; int offset; long min, max; int lifespan; unsigned long timer; };
----------- Timing variables, need to be Uint32, possible issues? ----
All of these instances are linked to variables that are used for timing / game tick management. I *THINK* they are supposed to be Uint32 and NOT Int32, it probably doesn't matter if they are 64 bit, but it can cause issues if compiled for x86 with 32 bit longs i think?...
I say they should be Uint32, because they are used in relation to variables which are indeed declared as Uint32
IMPORTANT NOTE: Robj, please correct me if timer overflow from 2147483647 to -2147483648 is ever used in magic DMOD trickery. I expect it shouldn't though, and letting timers run from 0 to 4294967296 should be fine?...
//game_engine.h, line 83 extern Uint32 thisTickCount; extern Uint32 lastTickCount;
Variable cycle_clock:
// game_engine.cpp, line 91 unsigned long cycle_clock = 0; // game_engine.h, line 78 extern unsigned long cycle_clock; // it interacts with thisTickCount in... // dinkc_bindings.cpp, line 1000 // this would cause issues if compiled for x86 cycle_clock = thisTickCount+1000; // freedink.cpp, line 436 // again, possible issues if compiled for x86 i think if (thisTickCount > cycle_clock)
Variable mold:
[code] // update_frame.cpp, line 64 static unsigned long mold; // mold interacts with thisTickCount in... // update_frame.cpp, lines 231, 232 if (thisTickCount > mold+100) { mold = thisTickCount;
Struct sp in live_sprite.h
//live_sprite.h, line 45, 51, 96 unsigned long delay; ... unsigned long wait; ... unsigned long notouch_timer; ... // all of these interact with thisTickCount in MANY places, therefore they // should probably also be of the same type, Uint32
----------- Used in file access, needs to be AT LEAST 32 bit ---
None of the dink files can ever reach sizes ranging in the GB, so 32 bits are more than enough for file access.
Variables of the struct refinfo, these all are used in file access, need to be at least Int32, but 64 bit not ever needed
//dinkc.h, line 58, 59 long location; long current; // current offset ... //dinkc.h, line 64 long end; // size of the text, == strlen(rbuf[i]) ...
These variables seem to be used in fseek, so technically it is not wrong for them to be "long", however, no map.dat file will ever be big enough to require long, so i think they should be changed for consistency anyway
//editor_screen.cpp, lines 97 and 211 long holdme,lsize;
These variables are used to refer to some file offsets in the dir.ff files. As far as i am aware, dir.ff files use 32 bit when storing offsets internally, so these should be Int32 as well...
// fastfile.cpp, line53 struct FF_Entry { unsigned long off; char name[13]; }; // fastfile.cpp, line 60 struct FF_Handle { int alive; unsigned long pos, off, len; }; // fastfile.cpp, line 88 FastFileInit(char *filename, int max_handles) { unsigned long count = 0; // fastfile.cpp, line 222 FastFileOpen(char *name) { struct FF_Handle *i; long fCount; long hCount; // fastfile.cpp, line 226 for (fCount = 0; fCount < (long)g_numEntries - 1; fCount++) // fastfile.cpp, line 230 for (hCount = 0; hCount < (long)g_numHandles; hCount++) // fastfile.cpp, line 241 unsigned long next_off = g_Entries[fCount + 1].off;