The Dink Network

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.

// 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;