Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Okay... what the fucking hell.

So I was taking those screenshots for the 4E5 screenshot thread, and the thing crashed right after I took the screenie of the component editor. I can't stand crashes - they're a sign of not caring about the code. And I care about the code.

Now, I trace the problem back to the component set loader code I wrote yesterday. Oh shit. Its a null pointer error. Which didn't make sense after checking the file it was loading (yay for textual data files?), because the file clearly allocates an object before writing to it in every situation.

So I go ahead and decide "You know, I should go ahead and add in null pointer checks just incase someone decides to hand-tool the files". And this fixed the bug, but I still didn't know what was causing it at this point.

I then run the test again to see what's going on, and I see the name for "Light Chassis A" to be "Lighta 1/4 ? Chassis A". What the fuck? Where the hell is this bad data coming from? I check the file again, and its still clean.

Walking through the code shows that the bad data is there when boost::tokenizer spits the stuff out. I then decide it probably isn't a bug with the tokenizer, so I check the raw file data. BOOM. There it is, right in the middle of an allocation command. And in the middle of the component name. the string '-32', '-68', '18'.

Now, I've ruled the problem down to the following code -

std::fstream file( filename.c_str() );
std::string dump;

while ( !file.eof() && file.good() ) {
char tempString[256];
memset( tempString, 0, 256 );
file.read( tempString, 256 ); // 256 -> 255
dump += tempString; // 1


Which I've been using to dump a text file into memory. So I check where in the file the bad data occurs. Suprise suprise, around index [256] and [512]. I'm probably just going to rewrite this bit, because I hate fstreams. C-style files would be much cleaner, I think.

For the record, I need a nice big string in memory because that's what boost::tokenizer wants to have. It doesn't concern me because its not performance-intensive code - its just to load stuff. Blah.

* goes and uses C-style files *

I'll write up some more design stuff tonight; wanted to make a code post :]

EDIT: Found the problem. std::string doesn't like you feeding it non-null terminated strings, which I was, in line #1. I made it only read in 255 characters, then leave the last one the way it was from the memset (ie, a null character), and it appears to work. Huzzah :D
Sign in to follow this  


Recommended Comments

So, Um, how does std::string know how long that array is?
As fstream (if memory serves) won't be adding a null termination in there in tempString[255]. So std::string will add that entire array, and keep going in memory until it happens apon a null termination.

Change the read to 255, and the problem will go away.

Share this comment

Link to comment
Yeah, I figured out the null-termination issue. I guess I kind of assumed it would be nice and null-terminate it for me or something. I've become too accustomed to the wonder that is std::string :)

I'll throw in your anti-magic number suggestion too. You can tell I'm not used to using C constructs :[

Share this comment

Link to comment
Original post by DukeAtreides076
Get your ass in gear, Pouya already has a DEMO!

Yeah... I'm scared too :[

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!