• 11
• 9
• 11
• 9
• 11
• entries
570
2427
• views
216646

# Untitled

76 views

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}file.close();

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

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.

Also, why not memset(tempString,0,sizeof(tempString)?

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 :[

Quote:
 Original post by DukeAtreides076 Get your ass in gear, Pouya already has a DEMO!

Yeah... I'm scared too :[