Back to General and Gameplay Programming

Convert hex to int

General and Gameplay Programming Programming

Started by monid233 June 03, 2011 07:26 PM

25 comments, last by monid233 12 years, 10 months ago

2,109

June 04, 2011 10:48 PM

That means I can safely use either unsigned x = *reinterpret_cast<const unsigned *>(HEX.c_str());
or the code you gave me earlier for the hex_to_int() function?

If by "safely" you mean taking care to ensure we don't read/copy more bytes than we've got or write to any location that we aren't sure we control, then yes, either approach will work. If you don't understand why, please feel free to ask (but state which part you don't understand!).

The hex_to_int() function that you came up with earlier in post #4 should use the result of a sizeof expression in the third argument of the memcpy() call. I mentioned that earlier, but I want to stress the safely qualification. You're not going to blow up your computer or anything

but bugs caused by being "unsafe" in these areas are incredibly hard to track down.

http://www.mr-edd.co.uk
http://bitbucket.org/edd

monid233

123

Author

June 04, 2011 11:00 PM

If by "safely" you mean taking care to ensure we don't read/copy more bytes than we've got or write to any location that we aren't sure we control, then yes, either approach will work. If you don't understand why, please feel free to ask (but state which part you don't understand!).

Safely as in, "my computer won't blow up and no bugs will be caused by the use of this".

The hex_to_int() function that you came up with earlier in post #4 should use the result of a sizeof expression in the third argument of the memcpy() call.

This is how it should be written?



memcpy(&x, HEX.c_str(), sizeof(unsigned));

I mentioned that earlier, but I want to stress the safely qualification. You're not going to blow up your computer or anything but bugs caused by being "unsafe" in these areas are incredibly hard to track down.

This part is a bit unclear to me. Are you implying that



memcpy(&x, HEX.c_str(), HEX.size());

is unsafe?

the_edd

2,109

June 04, 2011 11:10 PM

This is how it should be written?
memcpy(&x, HEX.c_str(), sizeof(unsigned));

Yes, but you *must* make sure that HEX.size() >= sizeof(unsigned), otherwise you'll be reading data from no man's land.

Are you implying that

memcpy(&x, HEX.c_str(), HEX.size());
is unsafe?
[/quote]
Yes. HEX is an std::string. It could contain 10000 characters. Writing 10000 characters over a 4 byte variable means you scribble over 9996 bytes of data outside of x. Who knows what those bytes were being used for? If you're lucky your program will crash. If you're unlucky it'll continue to run but behave strangely, crashing 3 minutes later in a seemingly unrelated piece of code.

http://www.mr-edd.co.uk
http://bitbucket.org/edd

monid233

123

Author

June 04, 2011 11:22 PM

Yes, but you *must* make sure that HEX.size() >= sizeof(unsigned), otherwise you'll be reading data from no man's land.





	string _hex = HEX;



	if(_hex.size() < sizeof(unsigned))

	{

		for(int i = _hex.size() - 1; i < sizeof(unsigned); i++)

		{

			_hex = '\x00';

		}

	}



	unsigned x = 0;

	memcpy(&x, _hex.c_str(), sizeof(unsigned));



	return x;

Applied the padding Trienco suggested. Better?

Yes. HEX is an std::string. It could contain 10000 characters. Writing 10000 characters over a 4 byte variable means you scribble over 9996 bytes of data outside of x. Who knows what those bytes were being used for? If you're lucky your program will crash. If you're unlucky it'll continue to run but behave strangely, crashing 3 minutes later in a seemingly unrelated piece of code.

Brings up recent memories...*shivers*

the_edd

2,109

June 05, 2011 12:06 AM

Applied the padding Trienco suggested. Better?

Does that yield a value that makes sense? Or would having to add padding imply that the data is malformed?

In other words, if you're expecting to be able to read, say, 4 bytes from a file and there are only 3 left, adding some padding is probably not what you want to do. It makes things well defined as far as the C/C++ languages are concerned, but it might not make any sense algorithmically.

http://www.mr-edd.co.uk
http://bitbucket.org/edd

monid233

123

Author

June 05, 2011 12:26 AM

Does that yield a value that makes sense? Or would having to add padding imply that the data is malformed?

In other words, if you're expecting to be able to read, say, 4 bytes from a file and there are only 3 left, adding some padding is probably not what you want to do. It makes things well defined as far as the C/C++ languages are concerned, but it might not make any sense algorithmically.

Good question. I'll have to look into this.

monid233

123

Author

June 06, 2011 07:06 AM

[font="arial, verdana, tahoma, sans-serif"]

[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"]
C) As said, each piece of data's size varies depending on the situation.[/font][/font]

[/font][font="arial, verdana, tahoma, sans-serif"]As it turns out, I got that wrong. Each chunk is four bytes in length. [/font][font="arial, verdana, tahoma, sans-serif"]So, reading less than four bytes would indeed be malformed data.[/font]

Convert hex to int

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Convert hex to int

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines