Jump to content
  • Advertisement
Sign in to follow this  
Endar

Returning a de-referenced NULL

This topic is 4592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just found this little code snippet in the source code of irrlicht 0.1
//! returns the axis aligned bounding box of this node
const core::aabbox3d<f32>& CSceneManager::getBoundingBox() const
{
	#ifdef _DEBUG
	os::Warning::print("Bounding Box of Scene Manager wanted.");
	_asm int 3;
	#endif

	// should never be used.
	return *((core::aabbox3d<f32>*)0);
}


Now, wouldn't the return cause really bad things to happen since you are basically de-referencing a NULL pointer?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Dereferencing something involves actually using it for reading or writing to it. Here it's just a casted NULL pointer that is returned - but not used.

Share this post


Link to post
Share on other sites
As it's irrlicht 0.1 and there's a comment above the return statement 'should never be used' I'm guessing this method was just a place-holder until the author got round to actually writing the real version. As to why it returns a de-referenced null pointer it has to return a core::aabbox3d<f32>& and that's probably the simplest way to generate something to return. Also I think the actual return statement would execute without problems as a reference is basically a pointer in disguise. Problems would occur when you attempt to use the returned reference. Officially in the C++ standard the effect is almost certainly undefined though so pretty much anything could happen.

Share this post


Link to post
Share on other sites
That code is evil.

Alternative suggestions for stubbed functions:

throw std::runtime_error( "function foo() unimplemented" );

assert( ! "function foo() unimplemented" );
exit( -1 );

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Dereferencing something involves actually using it for reading or writing to it. Here it's just a casted NULL pointer that is returned - but not used.


This code is an abomination. He's creating a null reference. People don't expect references to be invalid like that. Sure, returning it will work, but any attempt to use it will blow up. Have fun with that.

Quote:
and that's probably the simplest way to generate something to return.


If you look at the debugging string, it's trying to get the bounding box of an "abstract" object which doesn't have one. Why does that class possess such a member function? If it's to keep the class hierarchy simple, this is the right place to throw an exception. Deliberately tossing around null references is moronic. References aren't intended to be used as pointers.

Share this post


Link to post
Share on other sites
i think he simply has to return "something" to make compiler happy, and at this moment the class doesn't do anything other than throwing exception with "int 3".
But yes it's better to throw real exception.
Also i think it is bad idea to return reference to bounding box in first place.

Share this post


Link to post
Share on other sites
Of course, you do have to consider the fact that The Code Will Never Be Reached. If the function is entered AT ALL, it's an error - that's why theres a breakpoint in there. The only way to get to it is if the programmer enters the debugger.

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
Of course, you do have to consider the fact that The Code Will Never Be Reached. If the function is entered AT ALL, it's an error - that's why theres a breakpoint in there. The only way to get to it is if the programmer enters the debugger.

nope. If _DEBUG is not defined, you get null reference.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i think in a situation like this one you could also convince the compiler to shut up using __assure(false); .... evil code, i agree.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!