Complicated database problem

I have two programs that I wrote for work. One takes a huge text file database of airports, navaids, fixes for aviation and parses it, sorts it in alphanumeric order, indexes it and puts it all in a custom db file for the other program. The other one takes user input and searches for these fixes based on ID.

Problem is, with the latest publication, one of my coworkers noticed that the program would crash whenever someone started inputting a search string with a value less than '2F'. After much tinkering around I found that when I ran the program that makes the database on a work computer, I had a database that crashed the search program but when I made the database from the same source files using the same program at home, I had a working database.

Here's the real strange part. I wrote a third program to read the contents of each database file and compare them to one another and that program is saying that (based solely on content) they are *identical* in every way.

Both programs were written using Open Watcom. The DB builder is a 32 bit command-line program and the search program is a 32 bit windows program. The DB builder program uses no windows API's at all and uses fwrite() to write the data. The computers making the bad database are running Windows XP SP3, the computers making the good database are running Windows 7 Home Premium x64. The search program reacts the same to both databases whether it's run on XP or 7.

Each time I remake a database with my program, it has a different md5sum. I'm guessing md5sums might take the time/date of the file into consideration? Is there a hash routine that ignores the time/date of creation I could use to verify that they are identical byte to byte? Is there some part of the file other than content that might be different between XP and 7? Is there some subtext to fread() and fwrite() that might cause issues between these two OS's?

Try a binary comparison, instead:

On Windows use /B switch.

And welcome to the forum, Phane! :D

I'm guessing you mean using fc /b which spits out an extremely long list. Does that mean that the file is encoded differently despite being made with fwrite() in binary mode and getting identical data from them both with fread()?

Edit: I know why fc /b spits out a long list of differences while my testing program doesn't. I never zeroed out the memory allocated by malloc() and realloc() so all the unused space in my character arrays are random. It shouldn't make a difference, though, as all the arrays are properly terminated by zeroes which is why my testing program doesn't see the difference.

If you are starting to think about initialized arrays then perhaps you have latent arrays being accessed out-of-bounds / beyond valid data. Different environments could place harmless vs. harmful data in unassigned elements.

Quote:

---

Originally Posted by nonoob

If you are starting to think about initialized arrays then perhaps you have latent arrays being accessed out-of-bounds / beyond valid data. Different environments could place harmless vs. harmful data in unassigned elements.

---

I'm thinking this is a combination of two bugs, one in each program. The search program likely has the one you described and the builder program was putting the harmful vs harmless data there in the first place.

I found that I wasn't zeroing out the memory I malloc'd and realloc'd in the builder program, so random garbage from memory was being written to the unused portions of my character arrays in the database. I fixed that problem and now the builder program consistently creates a db file that passes fc /b and md5sum checks on both computers, and the search program no longer crashes with db's from either computer.

The search program must have a bug somewhere in there that was causing it to read some of this unused data, so I'll have to look into that. For now, it seems as long as that data is zeroed out, it's not a problem.

Thanks for the help. :)